FIPS for Erlang & Elixir Systems

2018-02-20
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

1. Hardware

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.

2. Operating Systems and Virtualisation

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

3. Application

Applications executing on the aforementioned hardware and operating system platforms also need to be compliant with FIPS-140 regulations. At this layer of a computer system, for the Erlang and Elixir ecosystem, we find systems and applications such as RabbitMQ, MongooseIM, Riak, Megaload, Phoenix and so forth, which would need to be altered via configuration or implementation in order to meet FIPS-140 requirements. These changes vary in complexity, and have dependencies on aspects such as the deployed version in use. (For instance, some legacy systems may possess less configurable features to cater for such alterations, and thus could require more specialist effort to achieve FIPS-140 compliance). The scope on applications is very broad, covering all intrinsic security related matters within the application itself, along with how these interact with the underlying platform on which they’re executed.

Fig 3: Erlang/Elixir Systems

4. Communications

In addition to an application being intrinsically FIPS-140 compliant, together with its underlying platform components, the security pertaining to how it communicates and interacts with other applications has to be FIPS-140 compliant as well. All communication, along with all post and pre-communication procedures carried out must be secure.

These requirements cross over a majority of the application’s intrinsic functions, with emphasis on the communication aspects. The Transport Layer Security (TLS) protocol is the dominant standard by which secure communications between multiple nodes is established. For Erlang based systems, this is a critical factor, as the backbone of most, if not all, interactions of multi-node deployments are based on the Erlang Distribution protocol. The implication is a need for a secure Erlang Distribution setup, in conformance to FIPS-140. Such multi-node/cluster deployments don’t come “out-of-box” by default, and require knowledgeable expertise in this arena to implement. Additionally if any other internode communication protocol is employed, similar conformance procedures to fulfill FIPS-140 would have to be put in place.

5. Operations

FIPS-140 defines requirements regarding security measures on post implementation procedures, for data acquisition functions, which span across aspects such as the system’s primary operational functions, audit purposes, OAM, and so forth, where the system in question is queried for various information during its uptime. Querying procedures could be typical request response procedures in client server architectures, or fetching of performance data such as statistics and and other queryable, exposed information deemed useful. Conformance to FIPS-140 in operational procedures are closely tied to the requirements stipulated on Communications.

Secure channels may have to be established for procedures such as statistics acquisition being rendered on web user interfaces, or logs being securely shipped to remote servers, and so forth.

Conclusion

That’s about it on the overview of aspects to be considered when provisioning FIPS-140 compliant Erlang/Elixir based systems. Alterations which would need to be implemented would vary depending on the application. Complexities involved would depend on aspects such as the system’s architectural design, implementation, dependencies in use, and more.

Each considered aspect would need a strong understanding of the system in question, hence vital activities such as architecture, code and deployment reviews are part of the background preparations that would need to be established prior to implementing any proposed FIPS-140 conformance changes. A FIPS-140 compliant labelled system definitely carries more weight and a strong reputation, bearing in mind the impression of trust it possesses and arenas of usage where it may be found, of strict security constraints.