A KEY MANAGEMENT CONCEPT FOR THE CTBT INTERNATIONAL MONITORING SYSTEM
Pres Herrington, Tim Draelos and Rick Craft, Sandia National Labs
Ernie Brickell, Yair Frankel, and Mark Silvestri, CertCo
DOE Contract No. DE-AC04-94AL85000
Sponsored by DOE
ABSTRACT
Cryptographic authentication (commonly referred to as "technical authentication" in Working Group B) is an enabling technology which ensures the integrity of sensor data and security of digital networks under various data security compromise scenarios. The use of cryptographic authentication, however, implies the development of a key management infrastructure for establishing trust in the generation and distribution of cryptographic keys. This paper proposes security and operational requirements for a CTBT key management system and, furthermore, presents a public key based solution satisfying the requirements. The key management system is instantiated with trust distribution technologies similar to those currently implemented in industrial public key infrastructures. A complete system solution is developed.
Key words: Authentication, Public Key, Key Management, Certificate, Certification Authority, Trust
OBJECTIVE: To develop an operational concept for management of cryptographic keys to be used in the CTBT IMS for authentication of sensor data and other digital products.
RESEARCH ACCOMPLISHED
Data collected within the Comprehensive Test Ban Treaty (CTBT) International Monitoring System (IMS) must be both authentic and accurate in order to provide value to its user community. In fact, many electronic data networks (e.g., medical records and banking) have similar authenticity and reliability requirements to support their user base. We suggest that the IMS implement techniques commonly used in other electronic networks to provide for authenticity and accuracy of the data generated within the system. In this paper, we show how these security techniques can be effectively implemented for the IMS.
The security of electronic networks is generally analyzed by studying threat models under various attack scenarios. The potential losses for various internal and external attacks are analyzed and the final system design reflects a balanced approach taking into consideration the cost of the system and potential losses under various compromises. We suggest that a similar approach be used for the IMS. Work done to date suggests that, without safeguards, the CTBT International Monitoring System is vulnerable to modification of sensor outputs within the territory of a host country even though this may be performed without approval of the host country’s government (an internal attack). Similarly, an internally-launched attack on the workstation of a data user can make fraudulent data appear to be authentic. In addition, an unprotected IMS is vulnerable to modification of any information after the data leaves the host countries (an external attack).
The most prevalent techniques currently used to protect a computer network from these types of external attacks are the use of cryptographic authentication complemented with various software and hardware shielding techniques to support the security of the cryptography. The authentication mechanisms provide a computational means in which modification of the source or the integrity of the message can be detected. The message generating entity computes an authentication element based on the entity’s secret key and the message. Verification of the integrity and the source of the message is performed using an authentication key. However, cryptographic authentication provides little protection against an insider who has possession of the secret key. Placing authentication units and keys inside tamper resistant devices, ensuring redundancy in data availability, and multi-point checking of integrity provide the primary approaches to protect against insiders. It is our belief that IMS security should be designed such that there is no single point of failure – a common standard used in the design of secure systems.
It is also our belief that cryptographic authentication and proper location of sensors are complementary security mechanisms which are part of a full system security design. We suggest that cryptographic authentication be used in the IMS to protect against modification of the source and/or the integrity of the message. Redundancy and multi-point checking to minimize the consequences of "internal attacks" is already incorporated into the IMS by proper location of sensors such that modification of the data of a few sensors does not compromise the detection of nuclear tests.
The inclusion of cryptographic authentication, however, implies the development of a key management infrastructure for establishing trust in the generation and distribution of keys. Though key management is an essential component for the protection of sensor data, its design can support the securing of other IMS products, such as commands used to control sensors or event bulletins and supplementary bulletins generated by the IDC or the NDCs.
The objective of this paper is to offer a complete key management solution to support the use of sensor data authentication in the IMS as well as other communications (e.g., sensor commands and event bulletins). The proposed system recognizes the absence of a single trusted entity within the CTBT community and takes advantage of the trust as well as distrust that is present between state’s parties.
The basic concepts of key management, public key signatures and certification authorities are reviewed in this section.
An asymmetric cryptosystem is one in which knowledge of a public key does not provide any computational information about the private key. One definition of a digital signature is:
A transformation of a message using an asymmetric cryptosystem such that a person having the initial message and the signer’s public key can accurately determine (1) whether the transformation was created using the private key that corresponds to the signer’s public key, and (2) whether the initial message has been altered since the transformation was made.
Hence, a public key cryptosystem allows for the verification of the source and integrity of a message. Moreover, since the system is an asymmetric cryptosystem the verifier learns nothing in the verification process which would allow it to sign new messages or modify previously signed messages.
Public key signatures are the standard method to perform authenticated communication among mutually distrusting parties in banking and other electronic commerce protocols (e.g., SET, digital cash, etc.). In our suggested system, public key signatures are used to authenticate sensor data and other IMS data products as well as to establish trust in the key management protocol.
Key management supporting public key systems
The basis of security in cryptography is secret keys and therefore an infrastructure which supports the secure management of the keys is a necessary component of any system. A key management system provides the underlying policies and mechanisms for executing and maintaining a cryptographic system. It provides all the service functions needed for the cryptographic components to work and, when specified correctly, permits the operational aspects of the system to be designed on their own. Its functionality includes:
Key generation: Establishment of a secure key for entities and processes. Generally this is accomplished by the entity that will possess the key after generation but this is not always the case. The primary concern here is that the key is known only to the entity responsible for signing information using the key.
Key distribution: Once a private key is generated the public keys must be disseminated to those who need it in a manner that permits the parties who accept the public key to trust that it is authentic.
Key maintenance: Addition, deletion & suspension of private/public key pairs is a normal operational aspect of any cryptographic authentication system. This means that the users of the system must be notified that old keys are not valid and that new keys have the functionality of the old ones. As in (2), it is imperative that this notification is performed using authenticated means.
Key archiving: When signed data is archived, it is also necessary to archive the public keys and to have a method for establishing that the public key was valid on the date that the data was generated.
Certificates and Certification Authority (CA)
A digital signature has limited utility unless the recipient can ensure the authenticity of the public key used to verify the signature. Hence, the receiver must receive the sender’s public key from an authentic and trusted source. If it can not receive the public key directly from the sender, then the most common technique for the receiver to obtain the public key is from a trusted source called a "certification authority". One organization defines a certificate as:
A computer-based record which at least (1) identifies the certification authority issuing it, (2) names or identifies its subscriber, (3) contains the subscriber’s public key, and (4) is digitally signed by the certification authority issuing it.
A certification authority is the standard method for establishing user trust in public keys. Currently, CAs exist for many applications including electronic banking, electronic commerce, and telephone and mail services. The CA infrastructure reduces key management to one trusted interaction with the CA and then later the CA attests to the validity of all public keys in the system by the signing of certificates. The certificates signed by the CA are used to establish the validity of public keys used in current transactions and the validity of archived public keys associated with archived data.
Security model for IMS sensor data
CTBT IMS entities, as well as those for other networks, can be categorized by the functionality which they perform with respect to the gathering and manipulation of data. Though simplistic we categorize entities as:
an information gathering entity (e.g., sensors),
an information retrieval entity (e.g., an NDC)
an information processing entity (e.g., NDC, IDC),
a data storage entity (e.g., NDC, IDC), and/or
a network control and management entity (e.g., host countries, NDC, key management control entities).
An information gathering entity has the purpose of gathering data which will be processed by the system. The primary security considerations with this entity are that the information it gathers is accurate and has integrity. An adversary may try to attack this type of entity either with internal attacks at its source or with external attacks as it disseminates the information it gathers. Cryptographic authentication protects against modification of data by outsiders after information retrieval, while tamper resistant devices, redundancy in data availability, and multi-point checking of integrity protect against internal attacks performed at the information gathering unit. In the IMS, therefore, protection of sensor data using both cryptographic authentication and proper placement of sensors provides a full system approach. Authentication protects against modification of data after it leaves the host country while placement provides additional information to protect against mis-information provided at the host country.
An information processing entity takes data held globally by the system and processes it. An information retrieval entity downloads data held globally by the system and displays it. Both of these entities require assurance that the information received is accurate and authentic.
A data storage entity, such as an NDC, stores the data collected by the information gathering entity or data processed by the information processing entity. This entity may require assurance that the data and information it receives are authentic. If so, the information it receives from information gathering entities and information processing entities must be authenticated.
Control and management entities are those that control the other entities in the system, usually by remotely generated commands. In order to assure that these controlled entities operate with integrity, the commands sent to them from control and management entities must be authenticated.
In addition to these requirements levied on the IMS entities, an IMS security solution should also address the following objectives:
High degree of sovereignty:
Multiple entities must trust the process:
Flexibility in State to State trust/dependence:
Preserve national integrity:
Low life cycle cost:
Key management solution
We now discuss our concept for a key management system architecture. This architecture implements a chain of trust relationships that makes it possible for information processing entities to rely on the authenticity of data received from sensors throughout the IMS. A summary of this solution is presented in the figure at the end of this paper.
The first trust relationship in our key management system is between information processing entities (e.g., NDCs and IDC) and a Certification Authority. It is the job of the Certification Authority in this architecture to generate certificates that information processing entities can use to verify signatures generated by the sensor sites in the IMS.
In order for an information processing entity to trust a certificate, the entity must have trust in the Certification Authority. Since there is no single trusted entity in CTBT IMS, we suggest using a distributed trust mechanism for the Certification Authority. This can be accomplished through a technology called threshold cryptography. The certification authority function will be split among a group called the "Oversight Committee". This committee will be constituted by some process agreed to by all CTBT signatories. In order for a certificate to be issued, all members of the Oversight Committee must agree that the certificate should be issued. This is accomplished as follows:
Each member of the Oversight Committee will have a secret partial signing key.
When a member of the Oversight Committee approves of a certificate, that member will form a partial signature of the certificate using their partial signing key.
After all of the members have generated partial signatures, these partial signatures will be combined into a single CA signature.
This distributed trust CA has the property that even if all but a single committee member generates a partial signature for a certificate, the final signature cannot be computed.
Information processing entities can trust the Oversight Committee based on one of two criteria. First, they can explicitly trust the reliability of one or more members of the committee. When this criterion is used, the information processing entities believe that the committee member(s) will not allow a certificate to be created if they do not trust the authenticity and security of the cryptographic keys associated with the certificate. Second, information processing entities can trust in the distrust built into the Oversight Committee. In this case, the information processing entities may not explicitly trust any of the members of the committee but they trust that the composition of the committee is such that all of the committee members will not collude to create a false certificate.
In an initialization process, there will be a public key generated for the Oversight Committee. This public key will be widely disseminated to all parties of the IMS. Although there are many cryptographic keys in the system, the CA simplifies key management by requiring an entity to store only this one public key of the CA, which is then used to maintain trust and security in all of the other keys in the system. In practice, for the sake of communications efficiency, IMS entities will likely store all sensor public keys after verifying their associated certificates using the CA’s public key. If desired, the certificates could be retained and reverified on each use.
Transfer of trust to a certificate
In order for members of the Oversight Committee to certify a sensor site, the members must believe that:
the sensor’s private key is known only to the device that signs sensor data,
the public key that is to be placed into a certificate for the site is associated with the private key in the sensor’s authentication unit,
the sensor and authentication unit are installed at that site, and
the sensor and authentication unit are operating with integrity (i.e., that the signed data sent from the sensor accurately reflects the signals being received by the sensor).
To assure that these things are true about a given site, the Oversight Committee will charter a team of "Observers" to visit the site and to oversee the sensor’s and authentication unit’s initialization process. As with the Oversight Committee, these teams will be constituted using a process established by the Provisional Technical Secretariat. Similar to the previously described trust relationship, trust between a given member of the Oversight Committee and a team of Observers is established either through explicit trust in one or more of the Observers or in the belief that the composition of the Observer team minimizes the possibility of collusion.
At an appropriate time in the site installation/certification process, the team of Observers will determine whether the installation and initialization procedures have been followed correctly.
The Observers will inspect the sensor / authentication unit installation for signs of tampering. It is assumed here that the sensor and its authentication unit will have been inspected by an agent of the CTBTO prior to their installation to ensure that they will operate with integrity.
The authentication unit associated with the sensor will generate a public/private key pair. This process can be performed jointly with the observers to prevent bias by the sensor and make sensor key generation a mutual effort. Only the authentication unit will know the private key but its public key will be published to the Observers.
The Observers will prepare a certificate request containing this public key and will send that certificate request to the members of the Oversight Committee. The Observers will also send authentication information so that the Oversight Committee members can verify that the certificate request came from the Observers and no-one else.
The Oversight Committee members will approve the certificate request and a certificate containing the sensor identification information and the public key will be generated and stored on a Certificate Server (i.e., a database system) for distribution to data users.
Through the above procedure, the trust in the observers that the authentication unit was properly installed at the site has been transferred to the certificate.
Transfer of trust to the sensor data
After the sensor is in operation, the certificate will be used to transfer trust to the information processing entity. The process is as follows:
All data from the sensor is digitally signed with the private key in that sensor’s authentication unit. The digital signature is sent along with the data.
Upon receipt of the signed data, an information processing entity verifies the signature using the public key associated with the sensor’s authentication unit. The public keys for the sites of interest to the information processing entity are held locally (e.g., in RAM or on disk) by the information processing entity
If, by chance, the signature fails to verify, then the information processing entity requests from a Certificate Server (probably located at the IDC) the certificate associated with the sensor that generated the data.
As all authentic certificates will have been signed by the Oversight Committee, the information processing entity can verify the authenticity of the certificate using the Oversight Committee’s public key.
Once the certificate is verified, the public key contained in the certificate is then used in an attempt to verify the signature on the data.
Depending on the operational concept of the information processing entity, the requesting of new certificates and the reverification of signatures can be performed on other computers than those used to process incoming sensor data and/or can be delayed until a later time.
A CTBT IMS key management protocol is proposed using distributed trust technologies, an approach is based on technology currently being used to protect other digital networks (e.g., banking applications). The proposed solution is both secure and cost effective.