Document Number C005602
Copyright (C) 2015 CONNOTECH Experts-conseils inc.
Verbatim redistribution of the present document is authorized.
This document is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Specifications subject to change without notice.
Table of contents
The Linux kernel has a wide range of use, from low end embedded computers built-in various electronic devices to high end server systems. In the present document, a novel use of the Linux kernel is proposed as a replacement architecture for the Hardware Security Module (HSM) as known in the field of cryptographic key management.
As a general background observation, the HSM concept is foremostly justified by information control strategies beyond mere technogical features. The evanescent security module is no different in this respect.
The evanescent security module concepts share with the classical HSM technology the need to isolate ciritcal secrets (notably private digital signature keys) from general purpose computer systems. In contrast with the classical HSM, the novel concepts facilitate the integration of application logic within the secure boundary (the classical HSM technology usually lacks software flexibility and works by offering raw cryptographic computation capability through an API -- application program interface).
An important property of security modules is that they become valuable by virtue of independent security audits. The classical HSM is usually certified for compliance to NIST FIPS 140-2. The evanescent security module takes a radically different approach to this audit requirement.
The present document applies to security modules for occasional usage in work sessions (critical computation sessions) with continuous trusted operator supervision. Other types of cryptographic digital processor are thus out of scope, including the cryptographic accelerators used for high throughput TLS servers. The contemplated usage context typically calls for dual operator control, as an important information control not based on technology.
The present document describes a Linux kernel usage, which is open source. CONNOTECH is using the concepts presented here for a proprietary detailed design, which is not reflected in the present document. Thus, the material presented here is wholly in the spirit of open source software, both as a credit granting declaration (the Linux kernel, the Crux distribution, the GCC tools, and the GNU build system are extremely valuable technologies) and an a tiny contribution to the open source community (by releasing the present document, we encourage the independent development of the evanescent security module concepts). The present document mutism about CONNOTECH proprietary developments serves two related purposes for the reader. Firstly, we avoid creating expectations for documented features that rest on implementations not available as open source. Secondly, some readers may be afflicted by the self-censorship of patented technology documentation.
A security module of either type (HSM or evanescent) is intended for a critical computation handling secret cryptographic key material, e.g. the digital signature of X.509 security certificates by a certification authority handling the private signature key. (Indeed we refer to the digital signature example as a staple critical computation in the present document.) The evanescent security module, as its name implies, does not exist permanently as an integrated device or item that keeps its computation capability, and not even its specialization. Instead, the evanescent security module is assembled from its components at the beginning of a critical computation session, and dismantled at the end.
An off-the-shelf entry-level computer box is used as the computing device. A main requirement is the ease with which a Linux distribution may be installed on this computer. Small size is a desirable characteristic for a lower total cost of ownership. As the technology and fields of use evolves, the actual products that fit these requirements vary. At the time of this writing, we use a fanless booksize barebone computer model with a 1 GHz processor frequency and 4 gigabyte RAM.
It is preferable for the computer box to be devoid of permanent storage. Indeed, outside of the critical computation session, the computer box holds neither data nor software needed for the security module operations, and a future session may use a different computer box of the same model.
Thus a critical computing session proceeds as follows. The trusted operators meet at the premises for the critical computation session, and bring the required components for the security module assembly: a computer box, a boot media (e.g. a USB or MicroSDHC flash memory) with the required software logic implementing the specific critical computation, and the input data to the critical computation. Among the input data, there are at least two components of the digital signature private key (as in an "M out of N split component" secret storage scheme) that must be present at once in a computer memory for the private key to be used by the digital signature software logic. A typical critical computation is not time consuming with the current processing power available in computer boxes of the current technology. Thus, once the computation is complete and its results are made available outside of the computer box, the temporary use security module is dismantled. Specifically, the computer box is returned to a state where no trace of the critical computation occurrence is left.
As the reader might have understood, the evanescent security module concept rests on trusted operators for the safeguarding of long term secrets critical to the security of the overall digital signature process. The classical HSM technology offers a recovery backup technique also using the "M out of N split component" scheme. The evanescent security module concepts uses such a scheme as the single mechanism for long-term secret storage.
The evanescent security module concept may be documented as a four-tiered scheme (the term tier may be replaced by layer or ring as the former may have no equivalent in languages other than English). With our 0-1-2-3 tier numbering, this document revision focuses on the details of tier 1, software installation procedures.
The tier 0 is the selection of elementary components to be relied upon in the other tiers. This applies to hardware components and to elementary information security techniques. The later category is somehow arbitrary. We tend to include the selection of algorithms within their respective class, like the selection of SHA-256 as secure hash function.
The hardware component selection at the tier 0 includes the input and output peripheral selection for the module integration. A peripheral compatible media type is intended to store secret components held by trusted operators between critical computation sessions. This is both critical in the overall process security and very challenging because no effective encryption technique may be applied without re-introducing yet another key management project. The details of our current decisions in this area are left out scope for the present disclosure.
Also within the tier 0 is the selection of an "entropy source" for secret random number generation. Not all critical computations have an explicit requirement for secret random numbers, but our evanescent security module proposal assumes one exists. A secret random source adequate for a critical IT security process can not be left as a software only issue, and should not be left as a usual operating system service. The Linux kernel project indeed comes with some facilities for secret random number generation, but a simple system with a fully deterministic boot sequence (which is what an evanescent security module instantiation ought to be) may well fail to provide adequate randomness. Possible entropy sources for a simple computer system is a whole field of study.
The tier 1 is the software installation precedures. It rests on the open source Linux technology, to be augmented with the tier 2 software logic. In a narrow technical perspective, there is nothing special to the installation of a Linux operating system on an auto boot USB flash memory with the automatic launch of the critical computation software. The main goal is to adapt the precess details to the desired ease of comprehensive software review.
The tier 2 is the software application logic. This is advantageously structured as an application development framework and the application logic as such, the development framework being reused for multiple application logic implementations.
The tier 3 is the integration of the evanescent security module critical computation in the context of system-wide processes, from a security perspective. This includes both technology intensive information controls (e.g. applying bulk encryption for confidentiality protection of critical computation results delivered to third party computer systems) and human aspects of critical processes.
In the selection of hardware peripherals for the evanescent security module as a tier 0 decision for our module development project, we decided to implement an embedded HTTP server in the security module. That would meet the requirements for both an operator console port (through an interactive dialog made of dynamic web pages) and a transport mechanism for data exchange with other computer systems (through the file upload and download mechanisms in the HTML 4 presentation language).
In view of the diversified HTTP and HTML specifications, many restrictions to the embedded HTTP server logic are preferably made explicit for a trustworthy security module. Such HTTP/HTML implementation restrictions explicitness is also useful for a security audit to remain a reasonable undertaking. These issues are addressed as a tier 2 consideration.
The inclusion of an embedded HTTP server in the tier 0 decisions may not address all peripheral requirements for the evanescent security module. For a reader familiar with FIPS 140-2 requirements, the notion of a "trusted path" may or may not apply to the logical channels offered by the embedded HTTP server. In other words, the required level of assurance about the evanescent security module proper performance of information controls may command the use of other input and/or output peripheral connections (in addition to the embedded HTTP server logical functions).
The Crux Linux distribution is used as the starting point for the software installation in our evanescent security module project. It is a simple Linux distribution maintained for a single leading processor architecture, X86_64 for the current Crux version 3.1. Its simplicity implies that the learning curve is steep due to the intrinsic complexity of integrating user space packages with the linux kernel targeting a given computer hardware configuration. As a counterpart, the Linux kernel modularity and the freedom in the selection of packages allows the tailoring of software istallation to the specific mission and hardware configuration for our evanescent security module project.
The coarse tailoring of the Linux installation comprises the removal of most of the networking support. We keep a single Ethernet wired connection on which two IP protocol support packages are used, SSH (with the security module being the server) and FTP (the security module being an anonymous client). The network topology is a single point-to-point route with fixed IP addresses, no gateway, and no domain name resolution. Correspondingly, the module software has no configured access to the Internet or an intranet. Moreover, the linux installation is devoid of a graphical user interface. Finally, many unused features may be removed through the Linux kernel configuration and software package installation. Finer grained tailoring may yield a Linux kernel making no use of loadable kernel modules and removal of unused portocol options from the source code base for open source packages, leading to a smaller source code base in which a security auditor might look for Trojan horse software injection opportunities.
The above software installation customization process is source code based, using conventional Linux kernel and open source software building tools. The Crux Linux distribution makes it easy to adopt this software installation model. However, the normal Linux distribution installation procedure (including the Crux one) routinely retrieves software components from servers on the public Internet, which comes with a theoretical Trojan horse injection risk. Accordingly, our software installation procedure systematically stores a local copy of software components retrieved from the public Internet by the original Crux installation procedure.
The software installation procedure must provide software audit snapshots. An audit snapshot is a collection of files that provides an auditor a very precise and comprehensive view of all source code software that is built as the sole executable software in the runtime environment that the audit process is expected to verify and accept. Obviously large portions of the source code has not even the slightest connection with the critical path in the critical computation, and the inclusion of these portions in the audit snapshot might appear as superflous. However, the Trojan horse software injection threat is present in every piece of software, and the auditor must be offered an opportunity to review all of them. This opportunity to review may act as a deterrent for attackers. Also, the auditor job is facilitated by the use of open source software present in the snapshot, merely because an independently downloaded source code package may be used as an audit reference for automated search of discrepancies in the audit snapshot version.
We use a simple ad-hoc SHA-256 utility for tagging an integrity code to an audit snapshot. It is somehow equivalent to the shell command line
find -type f | xargs sha256sum | sha256sum, the result of which is printed such that the auditor can detect a Trojan horse software injection occurring between the audit snapshot preparation and the audit work. This concern is representative of the level of vigilance that is expected for high assurance security modules.
The above generic Linux customization, installation, and audit snapshot preparation procedure is applied three times before the final application creating the security module critical computation boot media. This is because the software building environment should be available as an auditor target. In a nutshell, the compiling engine
c_comp_eng allows the software building targeting the critical computation engine
c_critc_eng bootable media, and the compiling engine is built either from a minimally customized Crux 3.1 distribution
c_crux3.1 bootable media, or a fully customized Crux installation
c_crux_min bootable media. Finally, in a circular configuration, the
c_comp_eng allows both the re-building of
c_crux3.1 and the initial and subsequent building of
c_crux_min. The compiling engine
c_comp_eng is a computer box of the same model as used for the security module except that it has a hard disk.
The development station on which the initial
c_crux3.1 boot media is created can be a Linux laptop computer. It is this development station that connects to the
c_comp_eng computer box through the direct Ethernet connection and makes available the locally stored software components as an FTP server service. The early stages of
c_comp_eng installation requires a system console (keyboard and display) but the installation of the SSH server eliminates this requirement for later routine use of the controlled compiling engine.
The SSH server installation has a dependency on the availability of the
c_comp_eng secret random source. Generally, the latter is not part of the Linux installation. Specifically, this occurs when the packages
openssh are configured to use the secret random source selected as a tier 0 decision instead of the default
/dev/urandom. The secret random source may require a kernel source code patch, support software building, calibration for each specific hardware unit, or other special arrangements.
As mentioned above, the compiling engine
c_comp_eng is used for boot media building:
c_crux_min initial and subsequent building, and
c_critc_eng building. The later operation is the central mission for the compiling engine, as the controlled computer box where multiple critical computation boot media
c_critc_eng are prepared from audit snapshot(s) made of source code. In preparing the autoboot Linux installation for the critical computation engine, further functionality restrictions should be applied. The kernel needs no support for memory swapping, and no file system for a hard disk. Networking should be further limited since neither SSH nor FTP are required. The HTTP embedded server is the only remaining protocol engine supported over the IP connection. The compiler tool packages need not be installed.
A difficulty may arise with the secret random source in the critical computation engine installation if the secret random source is dependent on a specific hardware component that requires calibration for each unit, or otherwise requires data preservation between critical computation sessions. In these circumstances, either the
c_critc_eng is restricted in hardware compatibilty or the evanescent security module is no more devoid of permanent storage. This difficulty should be appreciated with a proper understanding of an entropy source for cryptographic purposes. The security assurance about an entropy source rests only on a belief that the process used to generate random numbers is unpredictable and statistically correct at an experimental precision that is impossible to achieve. A further requirement is the prevention of external influence on the generated numbers. Is is suggested here that a satisfactory solution for a secret random source may justify some exceptions to the nice properties of an ideal evanescent security module.
An embedded HTTP server is a typical configuration mechanism for customer premises routers and firewalls. In the context of a security module, an embedded HTTP server implementation must be secure in some explicit respects, and must not be relied upon outside of those.
Here are samples of a security target and an insecurity aspect. In our security module project, the HTTP server logic must systematically remain in control of a single interactive session with a browser client user (the HTTP is a stateless protocol but various strategies are known to turn it into a stateful session oriented protocol). A security property that is left out of our project is confidentiality protection for data input by the web client user.
Mature software packages implementing HTTP servers are ill-suited to implementation in a security module as an embedded HTTP server. They are simply too features rich and their configuration as a minimal implementation would not bring a secure running server (e.g. the single session restriction is unlikely to be supported). Our security module projest uses an internally developed minimal HTTP server implementation.
A client computer browser implements the main operator interface for the security module. While it is conceivable to mandate the best industry practice for a secure client computer, the very principle of a security module is to restrict the critical computation logic to a single computer system. Thus, the reliance on client computer security is minimal (as a design decision in our project). It is accepted to assume with a low degree of assurance that the browser software will diplay the HTML contents correctly to the operator. It is not a demanding functional security target: it is easily achievable in practice. But an explicit fail-safe logic is necessary. The latter is implemented by the security module software logic which is within the high assurance boundary. Basically, the fail-safe requirement means that no harm is created if the operator is mislead into the critical computation session. In this context, no harm is created if the critical computation is not performed. This principle has to be implemented in the critical application design and may have implications at the tier 3 processes. For instance a digital signature critical computation may deserve an independent verification following the completion of the critical computation session. The verification itself may be automated but an exception handling provision in the tier 3 processes should be present for the possible verification failure.
Here is a further observation about the choice of an HTTP embedded server as a security module operator interface mechanism. The alternative would be a computer console. In either case, the security assurance rests on the absence of a back door. For a computer console, a back door may be a special combination of keyboard entries that brings up a kernel debugging mode or some other un announced interactive session mode. Furthermore, for a computer console, the security review may require the attention to various keyboard interfaces and various console emulation modes. With the HTTP embedded server choice, a back door may be any undocumented protocol support in the security module. As with the computer console alternative, a kernel-based back door is conceivable. However, kernel implementation of IP support over an Ethernet is less hardware configuration dependent that computer console support and may be independently verified with a protocol sniffer device recording the Ethernet connection traffic either as a security review activity or during a production session with the evanescent security module.
The evanescent security module concepts presented above present a path towards a new computing environment paradigm for critical computations done occasionally and for which trusted operator time allocation are economically justified. Technologically, a simple tailoring of a Linux distribution installation procedure is being presented. It is the ever present need to provide security assurance through independent security review that induces the contents presented here. It may be noted that the evanescent security model principles are not absolute when implemented, as the reader may have noticed. For instance, it is impossible for a computer box to be totally devoid of permanent data storage capabilities: some flash or EEPROM components will be present in every model. This being understood, it should not invalidate the proposal.
The main benefits of the proposed evanescent security module are the use of simple readily available components, the inclusion of application logic within a high assurance computing environment, the open source model which eases the security review process, immunity from the technology obsolescence threat, and a good overall fit to the challenges of key management ceremonies for heavily relied upon digital signature key pairs.