by Ayanda Dube
FIPS (Federal Information Processing Standards)[1] are a set of standards defined by the NIST (National Institute of Standards and Technology) to provide a means to govern and control how computer systems inter-operate in industry approved, credible and acceptable methods. FIPS-140 isn’t a necessity across the board, but if you’re operating in uncompromising sectors such as those found in governmental systems, I highly recommend you work to become FIPS-140 compliant. The FIPS-140 publication defines the standard requirements pertaining to cryptographic modules and functions employed in a computer systems, in all phases inclusive of, but not limited to, the design, implementation, installation, and usage.
The requirement for Erlang based systems such as RabbitMQ, MongooseIM, Riak, WombatOAM to meet FIPS-140 compliancy are on a rapid surge, due to their dense usage in mission critical environments, such as those found in governmental sectors where the security requirements are uncompromising, and of uttermost importance. These Erlang systems are comprised of multiple applications that operate as part and parcel of a stack of other underlying applications and subsystems, such as the Erlang Virtual Machine and Operating System. Thus, in order to fulfill FIPS-140 compliance, considerations must cut across these underlying, enabling, layers as well, with an emphasis on the operation and interaction with the validated FIPS security module(s). The following is a graphic illustration and discussion of the components and aspects considered in an Erlang/Elixir system in order to conform to the FIPS-140 standard.
Fig 1: Components and aspects to be considered for FIPS-140 compliance
FIPS-140 defines platform security requirements, from the hardware to the operating system along with its security libraries. The requirements on hardware span from classifying the types of hardware security modules, such as single-chip and multi-chip embedded cryptographic modules, in which aspects such as the physical covering and coating for protection against tempering are defined, along with other internal aspects such as zeroization of sensitive “on-chip” information, and more. In the scope of Erlang, embedded systems being developed and shipped with, for example Erlang-ALE (and Elixir-ALE or Nerves, for embedded Elixir systems) would need to take such factors into consideration on both firmware implementation, and hardware fabrication.
The requirements on operating systems govern the types (is it a trusted OS or not) and the manner in which the cryptographic software modules employed will function with regards to the provision of data protection as defined in FIPS-140 standard. These requirements are vast, and to the pleasure of developers and the community, libraries such as OpenSSL implement these feature sets, which, with good understanding, need be configured and enabled for FIPS-140 compliance upon execution. FIPS-140 recommends a modular approach to software design and implementation, and OpenSSL follows suit, realising FIPS-140 through a validated OpenSSL FIPS Object Module. Other libraries such as GnuTLS also incorporate FIPS-140 compliance as preferred by the user.
Also within the scope of aspects to be considered, encompassing operating systems fulfilling FIPS-140, are the spawnable virtual machines and instances, which encapsulate and act as containers for efficient provisioning of various applications. These could be in the form of fully-fleshed operating systems such as those provisioned by automation tools such as Docker, Kubernetes, CoreOS to application runtime virtual machines such as the Erlang Virtual Machine, JVM, .NET, etc.
Fig 2: Erlang
Read the rest of this blog post on www.erlang-solutions.com.
[1] https://csrc.nist.gov/publications/fips
Originally published at www.erlang-solutions.com on February 20, 2018.