CA2597209A1 - Apparatus and system for application-oriented encryption key management - Google Patents

Abstract

The inventive device acts as the guardian for a master secret key, and yet allows routine encryption and decryption of data fields by the application software.
Through its interface with the application computing environment, it provides the application with encryption and decryption capabilities enabled by the knowledge of the master key, but without providing the master key value itself to the application. In a preferred embodiment, this is achieved by symmetric key derivation: the application sends a derived symmetric key request to the device with a derivation context field, and receives the relevant symmetric key. The actual derivation algorithm is irrelevant outside of the device. For distributed databases or directory replication, each server computer is equipped with a device, each guarding a local copy of the master secret key, allowing encryption and decryption of data fields irrespective of their location.

Description

TITLE OF THE INVENTION
APPARATUS AND SYSTEM FOR
APPLICATION-ORIENTED ENCRYPTION KEY MANAGEMENT
BACKGROUND OF THE INVENTION

[0001] The management of end-user passwords in an organization's computer network has become a complex task with the ever increasing reliance on diversified computer hardware and operating systems. A widely endorsed industry approach is centered on directory servers compliant to LDAP, i.e. Lightweight Directory Access Protocol. An LDAP server system maintains a centralized directory of end-user data for authentication, access control, and authorization. The LDAP technology allows replication of directory data in multiple server systems. The present invention purpose is to facilitate the use of encryption for user passwords and other sensitive data fields in directories or databases like LDAP.

[0002] It is well known that hiding a secret in a modern computer system is challenging. The key management for local storage of encrypted secrets is part of this challenge. In essence, if an application secret is stored in encrypted form (i.e. not just hashed or processed by a one-way function), then a decryption key needs to be stored, and the hide a secret issue merely moved from the application secret to the decryption key. This problem has industrial implications with LDAP servers, which may concentrate the user passwords and other sensible data fields for a whole corporate network.

[0003] Communications with the LDAP service is typically restricted to SSL
protected exchanges, and a properly managed firewall would protect the hosting computer from generic computer penetration threats. Nonetheless, plain text storage of user passwords remain a concern. In an ideal world, the highly skilled support personnel who install and service the LDAP servers should have access to neither application secrets such as end-user passwords, nor an encryption key used to protect these application secrets. It is thus a purpose of the present invention to provide a key management process allowing low-skilled handing of the most critical cryptographic keys in the data field encryption scheme for an application server.

[0004] With respect to interconnection and interoperability standardization like the work of IETF and ITU, data field storage, e.g. password storage, in a directory or database is mostly a local matter. So would be encryption technology used locally to protect the confidentiality of sensitive data fields. End-user password storage in LDAP
directories is introduced, as the LDAP attribute name userPassword, in the experimental Internet RFC 2307 and in an Internet draft document draft-howard-rfc2307bis-01.txt, both entitled "An Approach for Using LDAP as a Network Information Service." A successor LDAP attribute name, authPassword, has been introduced in RFC3112, but seems seldom deployed. In this context, a few industry-standard schemes are provided for encoding password values, based on Unix crypt utility or secure hash SHA or MD5. None of these schemes support a good password encryption algorithm with sensible key management. Some directory server software packages support "LDAP password storage scheme plug-ins" as a mechanism to expand the password encryption options, but the actual mechanisms are likely to be attempts to hide a secret using a proprietary encryption algorithm, which is neither recommended practice in IT security nor likely to contribute to the prior art in the field.

[0005] There are rich sets of prior art contributions in the field of cryptography, as a technological base for securing computer applications. Symmetric key cryptography is well-known to provide encryption and decryption capabilities from the knowledge of an appropriate symmetric secret key. It is this type of cryptographic capability that the directory applications like LDAP need at the individual user granularity. A notably challenging aspect is to link the symmetric key used at the individual user level to some cryptographic key material that is remote from the vulnerabilities intrinsic to the application runtime environment, in a simple, efficient, and secure scheme.

[0006] Public key cryptography provides encryption capability without knowledge of a secret or private key, but the decryption capability still requires private key knowledge, so it is not directly applicable to the LDAP encryption need at the individual user granularity.

[0007] The field of public key cryptography provides session key establishment protocols, see e.g. NIST Special Publication 800-56, "Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography" and those indicated in the US patent 6,061,791 by the present inventor, notably the PEKE
cryptosystem, reference "PEKE, Probabilistic Encryption Key Exchange, 10 Years Later, Including the PEKEv1.25 Specifications" available in the Cryptology ePrint Archive as 2005/183 at http://eprint.iacr.org/2005/.

[0008] Session keys are designed to be renewed at the start of a session, if not more frequently. As such, they are ill-suited to direct application to directory data field encryption, where the life span of an encrypted value is typically not limited.

[0009] At least from an efficiency perspective, It is not necessarily advantageous to instantiate one public key operation for each directory operation like what is found in United States Patent 6,336,12.

[0010] The US patent application publication US 2003-0005300 Al entitled "Method and system to maintain portable computer data secure and authentication token for use therein" (hereafter the Noble disclosure) discloses an interesting cryptographic key management scheme, although for a very different usage context, i.e. encryption of computer files on laptops. The Noble disclosure key management scheme is part of a larger scope specifications, hence it is useful to summarize the key management characteristics that are attractive for directory entry encryption.
A master key ("key-encrypting key" in the Nobel disclosure) encrypts the individual file encryption keys. This master key is never exposed outside of a security token, achieving an isolation of important cryptographic key material from the insecure laptop environment (see [0052] in the Noble disclosure). Security rests on the end-user control of the security token. A secure session is established between the laptop file encryption software and the token using public key cryptography to establish a session key, implemented as an RSA-style mutual authentication (see [0060] and [0099] in the Noble disclosure). During the legitimate duration of the session, cryptograms of a file encryption key, i.e. encrypted with a master key, are sent to the token for decryption as files read and write requests turn into file decryption and encryption requests. Despite the noteworthy arrangement between the insecure laptop and the security token, the Noble disclosure is not readily applicable to LDAP directory entry encryption.

[0011] The IT vendor SUN microsystems offers the SUN [tm] One [tm] directory server software package having both an "LDAP password storage scheme plug-in"
and a general-purpose attribute value encryption feature, but none of these make use of master key isolation as found in the Noble disclosure. See pages 211-216 in SUN
document 816-6700-10, "Deployment Guide SunTM ONE Directory Server Version 5.2," June 2003 for the general-purpose feature, and pages 170-171 in SUN
document 816-6699-10, "Reference Manual SunTM ONE Directory Server Version 5.2," June 2003 for the password plug-in.

BRIEF SUMMARY OF THE INVENTION

[0012] An application server is a set of coordinated software components processing data stored in permanent computer storage, typically using a directory or database arrangement. As the application server processes individual transactions, it needs access to user passwords and other sensitive data fields.

[0013] In the context of the present invention, it is desirable to have password data fields properly encrypted in the permanent storage even if the transaction processing requires plain text password values in the computer system main memory whenever needed by a given transaction. However, the cryptographic key material for the encryption scheme should remain out of reach for would-be attackers.
Ultimately, these two goals are simply incompatible: if the application server benefits from the decryption capability enabled by the knowledge of the master key, nothing can really prevent a determined attacker from running a Trojan horse software that behaves exactly like the application software.

[0014] For the purpose of the present invention, the application computing environment is the computer system, or closely associated computer systems where the application server software runs. Actually, the invention provide encryption and decryption capabilities to the application computing environment, but provides few mechanisms to discipline the use of these capabilities by the application software. In the case of closely associated computer systems, it is assumed that the networking technology reasonably prevents the leakage of sensitive application data.

[0015] In information security system design, a common documentation strategy is the statement of a threat model, which defines assumptions about what an adversary is likely to attempt in order to break the security scheme. Here are a few observations about the implied threat model for the present invention.

[0016] (A) The application software runs in an application computer environment where runtime memory is concealed from the attacker. However, the attacker would have incentives to eavesdrop the runtime memory if a master key would reside in it, even momentarily. The adversary has unrestricted access to the permanent storage.

[0017] (B) Any master key is thus stored outside of the computer environment and its ordinary permanent storage, in a dedicated security processor, having concealment mechanisms resistant to the adversary.

[0018] (C) The threat model welcomes an instance of session key establishment protocol in order to set up a session key between the application software and the dedicated security processor, where a session encompasses multiple application transactions, e.g. until the application software restarts.

[0019] (D) Furthermore, the adversary is deemed to have lesser dedication to impersonate the legitimate application software in the session key establishment protocol, if the latter is "mildly" authenticated. In here, "mildly" means that data or credential used by the application software for the purpose of session key authentication may be stored in permanent storage, with or without ad-hoc obfuscation technique.

[0020] (E) Also, the threat model allows for storage of the master key outside of the dedicated security processor provided that a) the split component technique is used, and b) no master key component ever transits through a computer system that can possibly be accessed by application personnel.

[0021] (F) The threat model assumes that the adversary can not break the encryption algorithm directly, e.g. through brute force attack.

[0022] (G) Furthermore, master key confidentiality protection is not considered degraded by the mere passage of time.

[0023] As will be understandable from the remaining portion of the invention disclosure, the threat model fits a key management scheme which is efficient in its recourse to security mechanisms in light of threats and perils of actual computer system operations.

[0024] The inventive device is typically implemented as a dedicated security processor with a data communications interface to the application computing environment, e.g. SCSI, USB, Ethernet, or asynchronous serial. Typical tamper protection features should apply to the device, e.g. once put into production, the device firmware upgrade capability should not be operative unless all key material is previously erased.

[0025] The present invention uses a single master key held in a dedicated security processor connected to the application computing environment. When the application software starts, an instance of a key establishment protocol provides a shared session key used to protect the data link between the application software and the security processor. When the application creates a new password data field, it requests a record-specific encryption key, derived by the security processor from the master key and a derivation context field which can be selected either by the application or the security processor. The application may encrypt the password data field, store the derivation context value with the ciphertext in the directory permanent storage, and erase the record-specific encryption key. At a later time when the application needs access to the deciphered password data field, it supplies the derivation context field to the security processor, the processor repeats its key derivation algorithm, and supplies the record-specific encryption key. The application software is thus in a position to decrypt the password data field from its directory, without ever having access to the master key, which is not accessible in the application computer runtime environment. It is the connection with the security processor that represents the access to the password decryption capability.

[0026] Without departing from the spirit of the present invention, the encryption and decryption operations can be performed by the device itself which has unrestricted access to the master key from which all encryption and decryption capabilities are enabled. The important point in "encryption and decryption capabilities enabled by symmetric keys derived from a master key" is that the application can have these operations performed through data communications with the device, but application access to the master key value is prevented.

[0027] In relation to the broad categories of cryptosystems in the prior art, the present invention implements a symmetric key cryptographic scheme for routine key derivation or encryption and decryption, and an hybrid cryptographic scheme for the session key, and the session key establishment protocol, that protect the data transmission between the two computing environments.

BRIEF DESCRIPTION OF THE DRAWING

[0028] The figure 1 depicts a front view of the preferred embodiment of the inventive device.

DETAILED DESCRIPTION OF THE INVENTION

[0029] In session key establishment, a conventional exchange of messages between two computing environments carry public parameters and field values used in cryptographic computations, in an arrangement typically including one or more public key cryptography computations. A shared symmetric session key is the end-result of an instance of a session key establishment protocol.

[0030] A session key establishment protocol useful for the present invention must have at least one public key computation and it must be applied such that each private key, or secret parameter, that contributes to the session key value is secure, i.e.
remote from the assumed adversary capabilities. Leakage of a given private key or secret parameter may give a passive eavesdropper a direct opportunity to compute the session key from a record of the exchanged messages. We call such private keys or secret parameters "critical parameters" of the session key exchange.

[0031] This definition of critical parameters refers to the plain definition of a key establishment protocol, and without artificial transformation of a critical parameter into something else by locally splitting the critical parameter in either two components or a cryptogram and its encrypting key.

[0032] On the inventive device side, every critical parameter must be held wholly in the device itself, in conformance with the view of the inventive device as a self-contained decryption enabling apparatus.

[0033] On the application computing environment side, no critical parameter may reside on the permanent storage. So, any application-side critical parameter must be ephemeral, i.e. created just before the instance of session key establishment protocol and destroyed immediately thereafter. The concept of an ephemeral public-private key pair exists in the prior art, e.g. in the distinction between ephemeral Diffie-Hellman providing perfect forward secrecy, versus the authentication property of permanent D-H
key pairs. Secret random values, e.g. nonces, participating in a session key establishment protocol, are by essence ephemeral. It is well known in the art that truly random secret number generation on general purpose computers is challenging, but nonetheless the present invention relies on secret random number generation.

[0034] We may give an example of a private key that is not by itself a critical parameter of a session key establishment protocol. In the RSA-style mutual authentication, if a single private key is compromised, the mutually agreed session key remains concealed from a passive eavesdropper. For details, see the COMSET
specifications found in chapter 8, section 4 of Bosselaers and Preneel, "Integrity Primitives for Secure Information Systems, Final Report of RACE Integrity Primitive Evaluation," Springer, LNCS 1007, 1995. COMSET replaces the RSA cryptosystem by of a Rabin-Williams variant, but the idea is the same. In applying this example to the present invention, it is reasonable to use a permanent private key pair on the application-side for authentication purposes as we are about to explain. Note that COMSET relies on a random integer drawn by each party; this random integer is a critical parameter on the application side of the present invention when the application-side private key is deemed not critical. Indeed, the prior art of key establishment protocols using public key cryptography is devoid of protocols having no critical parameter on either side of the two-party exchange.

[0035] Using these principles, it should be obvious to someone knowledgeable of the field how to apply a given key establishment protocol, by first identifying a set of critical parameters on each side of the two-party exchange, and then enforcing the protection rules for the critical parameters, as set forth herein. In many cases, there is a single possible set of critical parameters on either side. In the COMSET
example, a minimal sufficient set includes either a party's private key or the party's random number. Such determination of possible sets of critical parameters is straightforward from the rule that a leaked critical parameter allows a passive eavesdropper to efficiently compute the session key. Omitting a private key or secret parameter from the set of critical parameters may have secondary security impacts that are irrelevant to the invention threat model, such as loss of perfect forward secrecy, or inability for the device to authenticate the application computing environment using the key establishment protocol.

[0036] A given session key establishment protocol design may encompass an authentication capability in either or both direction. Such an authentication mechanism provides a local security service: one computing environment authenticates the remote one when it validates results of cryptographic computations that prove possession of a given secret or private key or value by the remote party. On the authenticating side, the processor relies on static data that are assumed representative of the remote party configuration, e.g. a secret key or value shared with the remote party, a cryptographic fingerprint of a shared secret, a public key representative of a remote party's private key, a current count value for a permanent counter variable maintained by the remote party. Such static data exists before the start of an instance of a session key establishment protocol.

[0037] A record of such static data relied upon could be stored in an LDAP
directory. In embodiments that use authentication, the present invention works differently: for authentication by the device, targeting the application computing environment, a record of the static data relied upon resides on the device itself. This allows the device to be self-sufficient in preventing trivial attacks by an adversary using Trojan horse software impersonating the application software.

[0038] Actually, the inventive device local knowledge of static data relied upon for authentication may make use of the trust transitive property of the security certificate technology. An example would be a local configuration of one or more trust anchors for validating chains of security certificates, plus hard coded rules or parameters to indicate which end-entity certificates are allowed as authorized application computing environments, e.g. the presence of a private X.509 certificate extension may be representative that a certification authority endorses a public key for use according to the rules of the present invention. The trust transitive property of the security certificates technology does not change the central idea that the inventive device, once in an operational mode, remains self-sufficient in validating that a public key is representative of the remote party configuration. The inventive device itself is thus not subject to tampering. It is thus an advantage that any counterfeit certificate security incident can be investigated without including the inventive device in the culprit list.

[0039] The target of an authentication capability needs access to required secret key or value or private keys to prove its "identity" to the authenticating device in the session key establishment instance. This required data is sometimes called electronic credentials. It is the very lack of secure storage for the electronic credentials in the application computing environment that forces the present invention threat model to refer to "mildly" authenticated session key establishment. On the application side, the present invention expects a greater level of protection for ephemeral private keys contributing critically to the session key value than for permanent private key values used as electronic credentials.

[0040] Within the spirit of the present invention, a session key establishment protocol may need to be augmented with extra transmissions and/or protocol fields for authentication purposes, as in the case of the original Diffie-Hellman.
Someone knowledgeable of the field will easily identify the need of an addition to a session key establishment protocol design, which occurs when an application-side private key is part of an ephemeral key pair for the purpose of session key confidentiality.
Once the need is identified, such protocol addition is straightforward, using either symmetric key message authentication code, secure hashing, or digital signatures. A single cryptographic proof-of-possession value, sent from the application software to the device, is adequate for the device to validate the application software knowledge of the recently established session key, based on either a permanent shared secret or a permanent private key. An example is given later in the present disclosure as the protocol field "SHA2(ACHAL I SSKA)."

[0041] The device authentication capability authenticating the application computing environment may make use of a static session instantiation counter, incremented at each successful run of the session key establishment protocol.
Within the application computing environment, this counter variable is a dynamic data element in the electronic credentials. Within the inventive device, such a current session instantiation counter value is part of the static data values relied upon for authentication, i.e. "static" refers to long lived, but not necessarily constant.

[0042] In the basic form of the present invention, the application software does not authenticate the dedicated security device to which it is connected. It is nonetheless possible, and sometimes quite practical, to implement such mutual authentication.

[0043] We now turn to the security of data communications between the application computing environment and the inventive device based on the session key generated by an instance on the session key establishment protocol. This is an aspect of the hybrid portion of the present invention, more specifically the symmetric cryptography portion of the hybrid scheme.

[0044] The well known SSL or TLS protocol offers a wide range of features and options that have the potential to cover the present invention requirements for the whole hybrid portion. Likewise, the recently finalized pre-shared key TLS
specifications would cover the narrower requirements of security of data communications from the session key, e.g. in a present invention embodiment where the SSL or TLS
session key establishment sub-protocol would be replaced by something else. There are a few motivations for a simpler and tailored specifications base for an embodiment of the present invention. The typical present invention topology is a simple data link, perhaps limited to point-to-point connection, while the SSL/TLS assumes global network connectivity. There are a number of SSL/TLS options and parameters to be selected or negotiated between communicating entities, and the impact of each would need to be considered and addressed. Once SSL/TLS options and parameters are decided for the inventive device, incompatibility pitfalls may jeopardize the inventive device deployment potential. Finally, there might be security implications because the application-side SSL/TLS implementation is not as tightly integrated to the application software as it should to prevent sensitive data leaks.

[0045] The security of data communications from the session key implies the classical set of requirements in similar circumstances, including confidentiality, data integrity protection, replay prevention, data delivery assurance. Data origin authentication is implicitly provided by data integrity protection because the session key establishment includes provisions for authentication, at least in the direction where it is most important, i.e. for data sent out of the inventive device.

[0046] Confidentiality and data integrity protection are conveniently achieved through application of the CCM encryption mode of operation defined in NIST
special publication 800-38C. Replay prevention can be achieved by including a few data fields in the associated data allowed in the CCM specification, in order to make the context of transmission globally unique: a session identifier, a packet counter, and a direction flag. The session identifier may be a truncated hash of the session key.
Typically, two independent packet counters are maintained, one for each direction of transmission.
They are reset when the session key is established. Data delivery assurance may be achieved by the transmission of secured acknowledgment packets in the reverse direction of transmission, with empty payload, and the same context defining fields as the original packet. Little sophistication is required in the acknowledgment and retransmission logic, given the typical throughput and reliability of available data links.
However, proper validation of cryptographic integrity and replay prevention remains important.

[0047] This secured data transmission is used by the application software in the application computing environment to access the encryption and decryption capabilities that are enabled by symmetric keys derived from a master key. If the data link technology has packet length restrictions that are too limiting for the application use, segmentation and re-assembly can be achieved with a "more" flag included in the CCM
associated data. A "more" flag is set in packets that do not hold the last byte of an application message in their last byte of payload data, indicating that more data is to be expected in order to reassemble a whole application message.

[0048] It should be understood by someone skilled in the art that many detailed arrangements are possible in the inventive device to grant the application computing environment access to the encryption and decryption capabilities that are enabled by symmetric keys derived from the master key residing on the device. Moreover, encryption and decryption capabilities may be enhanced with cryptographic data integrity protection without departing from the spirit of the present invention, e.g. using a scheme like the CCM mode of operation that is already applied in another context in the present invention disclosure.

[0049] Key derivation is always performed within the inventive device so that the master key value is never exposed. The encryption and decryption operations may be performed either side of the application to device data link. The contextual data that drive the key derivation operation may be a byte string of application-specific data values, a counter value, a nonce, a salt value, or an arbitrary derivation context field value stored along the ciphertext in the directory as suggested above. The key derivation operation ensures that the ciphertext for a given plain text value is different with any change in the contextual data for key derivation.

[0050] A possible key derivation function uses a cryptographic hash function like SHA-2, as in DERIV=SHA2(MASTERICONTEXT) where MASTER is the secret master key, CONTEXT is the derivation context field sent by the application to the device, and DERIV is the derived key sent back to the application. While key derivation including a hash function allows variable-length context fields, derivation functions based on a block cipher are perhaps more efficient. A block-cipher based key derivation function might look like DERIV=ENCMASTER(CONTEXT XOR CONST) where ENCMASTER is a block cipher encryption function with symmetric secret key MASTER, and CONST is a constant value. Actually, the notion of key derivation is a general one including key-encrypting keys, e.g. as in the Noble disclosure. I.e. it is sufficient to state the key derivation function as DERIV=DECMASTER(CONTEXT) where DECMASTER is a block cipher decryption function with symmetric secret key MASTER.

[0051] An additional countermeasure against attacks to the device is a fixed limit on the number of concurrent session that an application can use to get key derivation or encryption and decryption services from the device. This is not rocket cryptographic science, but it is nonetheless an effective barrier, especially if operational discipline ensures that the dedicated security device is turned on only when the application server is up and running.

[0052] In the case of a multi-threaded application software design, it is perhaps convenient to have more than one concurrent sessions in order to reduce the average transaction latency, especially if the device has built-in hardware parallelism for key derivation or encryption and decryption operations.

[0053] For allowing computer room operators and security auditors to assert the correct operational state of the inventive device, a foremost status information is the current number of sessions established by the device with application computing environments. While this number is exactly the maximum allowed, a Trojan horse software in the application computing environment is blocked from maliciously querying the device, hence everything is fine if at the same time the application software is running smoothly while making occasional use of the current session keys.
Accordingly, if a single operator status information is to be displayed by the inventive device, it should be representative of the fact that the number of currently used session keys is the maximum allowed.

[0054] The present invention includes key management provisions for master key establishment and maintenance, including operations for backup, controlled recovery, and controlled replication, often termed life-cycle management operations.

[0055] Two processor-based capabilities are needed for the master key life-cycle management support. Firstly, initial establishment of a new master key from secret random data, with master key output in split components for later recovery and replication purposes. Secondly, the master key loading capability in the dedicated security processor, from split master key components. The other operations needed for life-cycle key management support are manual. Notably, this includes enforcement of key usage, which is achieved through manual controls over which master key components are loaded to which dedicated security processor units.

[0056] Split component storage and transmission of secrets is a traditional technique for concealment of secret value from an eavesdropper who would see all but one of the components. For two components, the classical technique uses binary representation of plain text P and a one-time-pad keystream K, the two components being the keystream K and the ciphertext C=(K XOR P), where XOR is the bitwise exclusive or operation. For three components, there are two independent keystreams K1 and K1, and the three components are the keystreams K1 and K2, and the ciphertext C=(K1 XOR K2 XOR P). Once every required components are input to the inventive device, the plain text is recovered by the equality P=C XOR K or P=C
XOR
K1 XOR K2. It can be observed that separate entry of a key exchange key K and a key cryptogram C=ENCK(P), where ENCK is a block cipher encryption function with symmetric secret key K, is functionally equivalent to traditional split component entry with two components. The split component technique is attractive for mission critical key management characterized by a small number of key instances within an organization, such as the master key for a distributed LDAP directory of end-user passwords in an organization.

[0057] The split component technique is used for controlled backup and recovery of the master symmetric secret key. In a preferred embodiment of the present invention, these operations allow LDAP directory replication in the presence of data field encryption, because multiple LDAP server sites may be equipped each with an inventive device that is loaded with a common master key input at each site with the split component technique.

[0058] The use of the inventive device as a system component in a replicated directory application, or distributed database application, benefits from a common master key allowing a data field to be encrypted and decrypted irrespective of its location within the replication topology. The cryptographic key material used for session key establishment, and associated authentication capabilities as the case may be, need not and should not be global.

[0059] From a security and auditing perspective, it is advantageous that the master key components never enter the application computing environment where they would be subject to the same vulnerabilities that the device is intended to counter.
Thus, the master key input capability to the device should use an interface to the inventive device that is independent from the application computing environment. Also, this isolation requirement suggests a data storage media that is easily interfaced directly to the device, and is as immune as possible to aging impairment and technology obsolescence. The bar code printout scheme is readily applicable to the present invention. It is comprehensively disclosed in a similar context in the reference "Server Management Tools for Trust Anchor Key Management Based on TAKREM"
written by the present inventor and available at http://www.connotech.com/trustanchfoundry_09.pdf, and incorporated herein by reference. This reference provides details about bar code printouts for manual key management and suggests the use of a secret-sharing scheme such as 2 out of 3, out of 4, and 3 out of 4, where the a first number of cooperating key custodians are required to recover the secret, to be drawn from the second number of key custodians.
Another possibility for key component storage is portable memory media like the ones known by the trade name iButton. The older-fashioned manual key component entry through a device keyboard is also conceivable, although the larger size of modern cryptographic key material makes this option less convenient.

[0060] The recourse to manual procedures for master key life-cycle management avoids another layer of cryptographic scheme management that would be required if computerization was applied to every operation in the master key life-cycle.
Such additional security management can only shift the focus of manual procedures, but can not eliminate them. Moreover, the dedicated security processor would become intrinsically more complex, hence likely to be installed and serviced by the same skilled personnel as the application server itself, and thus defeating the very separation of duties that is highly desirable for countering insider threats.

[0061] Despite an apparent complexity of its operating principles, the deployment of the present invention is as straightforward as 1-2-3. First, setup a master key for the (possibly replicated) directory or database. Second, configure an inventive device connected to each of the application computing environments where the application software is intended to run. Third, load the master key in each of the deployed inventive devices and validate that the application is running smoothly.
Separation of duties for controls and auditing of IT security functions is conveniently achieved where the first and third steps are controlled by personnel other than the application software experts. The third step is a relatively low skilled assignment.

[0062] A given master key becomes a critical IT security asset only the first time when the third step is completed for a production application software. In symmetric key cryptography as in the present invention, master key generation is not a complex operation, despite unique requirements for truly random secret number generation.
Master key generation consists of a secret random selection of a master key value, preparation of key components (using the split components technique for storage and transmission of secrets), the media output operation for each of these components, the delivery of each component to an independent key custodian, and the reliable erasure of any trace of the key generation operation (including swap files on hard disks and printer buffers if the component media is a bar code printout). If properly audited, a master key generation operation gives a secure master key. The auditing discipline appears more instrumental to security than the use of dedicated hardware, and unsophisticated software and stand-alone computer equipment are perhaps well suited to the task.

[0063] The security of the mission-critical master key is better preserved by some logical ordering of the steps required to bring the inventive device up to an operational state. Whenever a new firmware version is loaded in the device, all configuration and keying material should be erased. Accordingly, for a device model designed to be field-upgraded by the customer, the factory-installed firmware loader should erase a portion of the internal memory where the firmware should store the configuration and keying material, including the master key, an operation known as device zeroization. Also, a record of the static data values relied upon for authentication of the application computing environment should be configured before a master key value is loaded. This configuration step may include a fixed datalink address for the application computing environment. Otherwise, it might be possible to fraudulently redirect the services provided by the device to an hostile application software. Also, the configuration of authentication-related data may require special test modes, for troubleshooting purposes, that should be disabled altogether once a master key is loaded. Thus a device zeriozation, including a master key zeroization, must be effected by the firmware whenever a change occurs in the device connectivity configuration, including data communications parameters and static data relied upon for authentication. In this context, it is easily understood that session instantiation counter increment is not a configuration change.

[0064] Although the present disclosure refers to the inventive device as a single purpose apparatus, it is conceivable for the present invention operating principles to be co-located in the same enclosure and/or electronics as other functional entities, however with a requirement for logical isolation or partitioning to prevent leakage of secret key material or tampering with data relied upon for authentication purposes. The type of isolation or partitioning envisioned in this context is also present in the avionics industry for safety certification of software present in civilian aircrafts, where a partition barrier in a processor system architecture is intended to prevent consequences of software bugs from propagating from less critical software functions (e.g. a weather radar display manager) to more critical ones (e.g. an autopilot controller).

[0065] We turn now to the disclosure of a detailed design of the present invention as they are readily known to the inventor at the time of filing a patent application. Design refinements and changes required to fix inadvertent errors are to be expected, as should be obvious to someone knowledgeable of the field starting from the whole invention disclosure.

[0066] The inventive device can be a 19 inches rackmount device (100). It needs no moving part, except for a possible power on switch (101). There is no need for operator feedback beyond two LEDs (Light Emitting Diodes), a red one (102) and a green one (103). Blinking patterns may be used to convey overall status information.
The data link is conveniently implemented as a 100Mbps Ethernet connection with back-to-back topology, i.e. no collision detection and full-duplex operation.
An RS232 serial port (104) is well suited to the task of inputting master key components with a low-cost bar code reader attached momentarily to the port, assuming key components are stored on printed bar codes. The Freescale (formerly Motorola) PowerPC
processor family has processors well suited to the task, and software tools are readily available, including compilers, low-end embedded systems kernels, and source code with BSD-style licensing for cryptographic primitive implementation. A low-end kernel is preferred to a full-blown operating system for sake of easier security software certification. Small single-board-computers are commercially available for the PowerPC family, including flash memory so that no hard disk or removable computer media is needed in the device design.

[0067] Once the firmware is loaded in the inventive device, it enters the initial configuration state. Once the connectivity configuration is complete, including authentication-related data, the device may enter the key loading state, which is actually entered when a first master key component is scanned into the device with a bar code reader. During the key loading state, the only allowed operation is the scanning of additional master key components. The scanning of the last master key component turns the device to its operating state.

[0068] The device protocol on the data link has a four sub-protocols, respectively 1) data link configuration sub-protocol, 2) session key establishment parameters setup protocol, 3) session key establishment, and 4) secure session sub-protocol.
The first two are allowed only when the device is in the initial configuration state.
The last two are allowed only in the device operating state. Some type of alerting messages may be supported by the device to bring it back to a previous state, with appropriate zeroization of key material and/or configuration data. The application-level messages are encapsulated as payload data in the secure session sub-protocol.

[0069] The design uses the PEKE cryptosystem as a base for the session key establishment scheme, the PEKE server role being assigned to the device, extending PEKE with client-side authentication based on a shared secret key established in the device initial configuration state.

[0070] The data link configuration sub-protocol should allow the device to learn the application computing environment Ethernet address. Likewise, the data link identification of the group of inventive sub-protocols may be a local selection, perhaps even colliding with IP frames, so that packet eavesdropping with common network troubleshooting tools is inconvenient, as a deterrent for insider fraud attempts. This is simply achieved by recording the source address of Ethernet frame, and the data link protocol identification as the case may be, when the device receives a valid frame in the session key establishment parameters sub-protocol.

[0071] The session key establishment parameters sub-protocol is a sequential handshake: 1) the application side sends a request for PEKE parameters generation by the device; 2) the device replies with its PEKE public key and other PEKE
parameters and a PEKE first message appended to the reply; 3) the application side sends a PEKE
second message, establishing the shared secret key for authentication, SSKA;
4) the device replies with a random challenge value, CHAL; 5) the application sends SHA2(CHAL I SSKA) as a proof of local knowledge of SSKA. AES is the preferred encryption mechanism, and SHA2 is the preferred cryptographic hash algorithm.

[0072] Session key establishment starts either with the application sending a request to initiate an instance of session key establishment, or the device sending a PEKE first message on its on initiative (collision handling has to be worked out). An application request message deserves a reply from the device, i.e. again a PEKE first message. A portion of the shared secret string becomes the session key, SSK;
another one becomes an authentication challenge value, ACHAL; yet another one becomes the session identifier, SI, for the secure session sub-protocol; packet counters in both directions are reset, again for the secure session sub-protocol. These operations occur on the application side before it sends the PEKE second message appended with SHA2(ACHAL I SSKA) to the device; these operations occur on the device side once it receives this last application message and validates it as a proof of successful completion of the PEKE exchange and remote knowledge of SSKA.

[0073] The secure session sub-protocol has data frames in both directions, and acknowledgment frames independent of data frames. The NIST CCM mode of operation is used in both types of frames, however confidentiality protected data is present only in data frame to carry application-level messages. The CCM
associated data contain the following protocol control fields: frame type code, direction flag, session identifier SI, packet counter in the relevant direction. Segmentation and reassembly with a "more" flag is implemented as a frame type code, hence the valid codes are "data, last potion," "data, non-last potion," and "acknowledgment."
The details of the acknowledgment and retransmission logic has to be worked out, in which a frame retransmission should use the same counter value.

[0074] The application-level messages are command messages from the application, and response messages from the device. There are two commands.
One is "request a derivation key" from a derivation context field, CONTEXT. The other one is "create a derivation context." In both cases, the response contains both the derivation context field and the derivation key, (CONTEXT,DERIV). With this arrangement, the derivation context field somehow acts as a "command identifier" allowing out-of-sequence responses from the device, although the corner cases of colliding derivation context fields should be worked out. In the present design, CONTEXT values are bits long and DERIV key values are 128 bits long. The derivation algorithm is DERIV=ENCMASTER(CONST I CONTEXT) where CONST is a manufacturer-specific constant value, 64 bits long.

[0075] It is thus convenient for the application to store an encrypted data field value as the pair (CONTEXT, ENCDERIV(VALUE)) instead of the plain text value, notation VALUE, where ENCoER,V(X) is a symmetric encryption function using key DERIV.
Obviously, at a later time the application can query the device with the CONTEXT value to retrieve the DERIV value that enables the decryption of the stored encrypted data field value. With this arrangement, the application selection of encryption algorithm, mode of operation, block padding, and the like, is independent of the device support of cryptographic algorithms.

Claims (9)

-26-What is claimed is:

1 A security dedicated computing device a) having data communications means allowing an application computing environment access to the encryption and decryption capabilities that are enabled by symmetric keys derived from a master key, a.1) where said master key is held within the confines of the device, a.2) where said data communications means are secured based on a symmetric session key obtained by an instance of a key establishment protocol using at least one public key cryptography primitive, a.3) where every critical parameter of said instance of a key establishment protocol that is used by the device is held within the confines of the device, a.4) and where every critical parameter of said instance of a key establishment protocol that is used by the application computing environment is ephemeral, b) and furthermore having programmatic control means preventing the simultaneous use of more than a fixed number of said session keys.

2 A dedicated security computing device as in claim 1, where the device displays operator status indicative of equality between said fixed number and the current number of simultaneous uses of said session keys.

3 A dedicated security computing device as in claim 1, a.5) where said key establishment protocol includes provisions for the device to authenticate said application computing environment, a.6) and where a record of static data values relied upon for said authentication by the device is held within the confines of the device.

4 A dedicated security computing device as in claim 3 further having programmatic control means zeroizing said master key whenever a configuration change occurs in said record of static data values.

A dedicated security computing device as in claim 4 further having an input capability for said master key in at least two separate input components, using input data rules that conceal the actual master key value from an eavesdropper of all but any one said separate input components.

6 A system comprising at least one application computing environment each having a security dedicated computing device attached via a data communications link;
a) wherein each said an application computing environment accesses, through its respective data communications link, encryption and decryption capabilities that are enabled by symmetric keys derived from a master key;
b) wherein said master key is held within the confines of every said device;
c) wherein each said data communications link is secured based on a symmetric session key obtained by an instance of a key establishment protocol using at least one public key cryptography primitive, where every critical parameter of said instance of a key establishment protocol that is used by the respective device is held within the confines of the respective device, and where every critical parameter of said instance of a key establishment protocol that is used by the respective application computing environment is ephemeral;
d) and wherein each said device has programmatic control means preventing the simultaneous use of more than a fixed number of said session keys.

7 A system as in claim 6 wherein said instances of a key establishment protocol include provisions for the respective device to authenticate the respective application computing environment, and where a record of static data values relied upon for said authentication by the respective device is held within the confines of said respective device.

8 A system as in claim 7 wherein each said respective device has programmatic control means zeroizing said master key whenever a configuration change occurs in said record of static data values held within the confines of said respective device.

9 A system as in claim 8 wherein at least one device has an input capability for said master key in at least two separate input components, using input data rules that conceal the actual master key value from an eavesdropper of all but any one said separate input components.