System security is a broad term which covers all areas of security within information technology, from physical security, such as locks on doors, through to software to perform cryptographic functions (Ford). This paper will concentrate on a small but interesting area of software security based on public key cryptographic technology.
Public key technology is seen by many to be both more cryptographically secure than symmetric key techniques and more easily scalable. Several reasons exist in support of these beliefs:
Public key technology does however suffer from similar problems to those experienced by symmetric key systems such as Kerberos, Sesame and standard Unix login security. The most obvious problem is that of key management where keys must be generated and passed around throughout the system. The problem is somewhat different between symmetric systems and public key systems. Key negotiation is required in symmetric systems so that the secrecy of keys is maintained whilst in public key systems, broadcast of public keys and establishing trust in the public key is the main requirement. Symmetric key systems use trusted third parties, sometimes called Key Distribution Centres (as in Kerberos), to manage this process and an analogous technique can be used in public key systems.
Public keys may be maintained in a database with associated subject identity and other information; each record is known as a certificate. Certificates however, do not by themselves enhance the trust in the system as a trusted third party is still required to create the certificates and prove trust. The trusted third party is known as the Certification Authority (CA) and it enables trust using a public key technique known as digital signatures (see Figure 2).
Digital signatures are a technique which uses an entity's private key to encrypt a message digest (checksum or message hash) calculated on a message. This enables other entities to verify the signature by decrypting the signature using the signing entity's public key and comparing with a message digest calculated on the message locally. Digital signatures prove integrity of the message and authenticity if the public key can be trusted to be authentic.
Since the CA's public key must be well-known by all clients, and since it is a cryptographically strong ('hard to guess') key, the CA can provide trust within the system by signing all certificates it issues. As long as the signing CA's public key for any certificate is known and trusted, the certificate can be trusted and used as proof of a binding between a client and a particular public key.
The key management problem is now apparent. How are certificates passed around a public key system and how is the CA's public key, which is used to verify certificates, broadcast/published securely? These problems can be resolved by the provision of a Public Key Infrastructure (PKI) which supports certification and broadcast of certificates using a simple architecture. It is a desirable feature of this PKI architecture that it be easily scalable to enable support for very large network environments such as the Internet.
The basic architecture of the DSTC PKI follows the client-server paradigm with 3 main servers: the Certification Authority (CA), Certification Server (CS) and Certificate Revocation Server (CRS) (see Figure 1). These main servers form the basis of the PKI structure conceptually known as a domain. The CA is the only server residing within the Trusted Computing Base (the highly secure core machines and servers) of the domain. The interdomain interface is provided to clients and the other PKI servers by the CS, which communicates with other domain CSs to request or send interdomain information.
Version 1.0 of the DSTC PKI is based on X.509 version 3 certificates and recommendations implemented on top of OSF's Distributed Computing Environment (DCE). However, ASN.1 support has not been included, which limits the interoperability of this prototype with other X.509 implementations. ASN.1 support is planned for PKI version 2.0 which will enable a full implementation of the X.509 version 3 standard and increased interoperability.
DCE is used within the PKI for basic type and transport encoding. It also provides the facility of authenticated RPC which enables on-line certification. We plan to add support for TCP/IP communications in Version 2.0 which will increase the user base for the prototype, but will force off-line certification. Off-line certification is however, a much more secure method of establishing identity, and more suitable in the PKI milieu than assuming authentication by DCE.
Version 1.0 of the DSTC PKI has rudimentary support for interdomain services such as certificate and certificate revocation list (CRL) retrieval as well as cross-certification of domains. Subsequent development for Version 2.0 will include extending trust routing strategies and investigation of caching and revocation strategies for interdomain operation.
On top of the architectural details, a client Application Program Interface (API) is provided, with C bindings, for development of applications which may want to utilise the PKI and PK cryptography for security services. A full spectrum of API calls is made available to applications enabling certificate management and manipulation, public key cryptography calls (encrypt, decrypt, sign, verify, etc.) and well as routines to interface with the main servers.
The DSTC PKI project began in early 1996 and is expected to progress to Version 2.0 before the end of 1996. At the time of writing, it is stable at a 2.5 person project. It is intended that the outcome of the project will be used as a research platform for investigation of open research issues with the possibility of commercial development and release.
There are a number of working groups on the Internet which are primarily concerned with public key technology and infrastructure. The most notable of these is the PKIX Working Group (Housley et al.). Recently, OSF published an architecture specification for PKI which details a basic PKI framework and considerations (Anderson et al.).
Due to the likelihood of public key uptake in electronic commerce systems of the future, there is significant interest in the legal issues involved. Various countries have developed or are developing frameworks, including legal specifications, for the use and regulation of public key technology. Australia, for instance, recently published a document called The Australian PK Authentication Framework (PKAF) and a corresponding request for comments. This document discusses the legal ramifications of various uses of public keys such as non-repudiation and digital signatures.
On the technology side of the public key arena, there are a number of major players. The cryptographic techniques are patented and copyrighted by a United States company called RSA (Rivest et al.). RSA-based public key cryptography is the most common, but there are other similar public key techniques based on similar concepts such as El Gamal. Pretty Good Privacy (PGP) by Phil Zimmerman, based on RSA techniques, is one of the most widely used of these public key technologies (Zimmerman). PGP is quickly growing in acceptance on the Internet, largely because it is freely available and runs on many platforms including PCs. A variety of message digest technologies are available, again the most common techniques, such as MD5, are produced by RSA (Rivest).
Since trust in a PKI system resides within the certificates themselves, the CA must be a trusted entity, but no such requirement need be placed on the CS. The CA must reside within the trusted computing base of the installation and be maintained by a trusted administrator. Two interfaces to the CA are provided to clients: one to create certificates and one to revoke certificates. The CA has no other interfaces to external clients. Certificates and Certificate Revocation Lists (CRLs) are registered with the CS by the CA.
The CS receives Certificates and CRLs from the CA and stores these items in the corresponding database. The CS provides several other interfaces to clients within the local domain as well as an interdomain interface. Clients may contact the CS, requesting certificates by subject name or serial number; they may also request CRLs from the CRS interface. Interdomain clients may access the same facilities through the local CS. The CS may reside anywhere within the installation and need not be trusted as it merely stores certificates in which the trust is inherent.
The provision of services from separate server entities facilitates the partitioning of the larger network into localised domains. Smaller domains enable local security management and reduce the administration overhead to achievable levels. Each domain would maintain its own internal PKI structure of CA and CS/CRS servers and certified clients. Interdomain trust however, becomes somewhat more difficult to resolve. In order for two clients to establish trust, each must be able to retrieve and verify the other's certificate. This process follows the outline:
The CA is the trusted third party within the system by which all trust is propagated. It is a highly trusted and secured piece of software and must reside within the trusted computing base of the installation to maintain the trust in the local PKI domain and overall PKI hierarchy (see below for discussion of hierarchies). The CA certifies clients within the domain, proving in a trustable manner that the holder of the private key matching the certificate is indeed who they claim to be. This can be achieved in a variety of ways:
The CS and CRS are servers which interface the clients with the back-end certificate and revocation list databases (which could be as simple as files). These servers are quite simple and need not be trusted, as all trust resides within the certificates or CRLs by the CA signature. Clients make requests of these servers and verify the return data using the CA public key, which must be a well-known and widely published datum and which may be retrieved with high assurance of authenticity. Because of the similar nature of the CS and CRS these servers may execute as a single entity, running separate threads for the two different roles.
Clients are provided with an API which may be used within applications to interface with a variety of PKI services and public key functions. Certificate and CRL manipulation as well as public and symmetric key cryptographic functions are provided within the API.
The simplest PKI system is comprised of only a single domain within which all entities exist. This simplifies certificate validation issues such as locating the CA public key, but cannot be used in the real world as the sheer size of the domain would be unmanageable and very few, if any, entities are willing to share trust in a single CA. Each organisation has its own unique set of trust requirements which can easily be localised within its own domain, but not in a single super-domain.
Splitting the world into domains alleviates some problems, but creates others. How does one domain establish trust with other domains? How does a large collection of domains interwork? How are certificates passed around between domains and how are they verified? These problems can be resolved by addressing the routing problem inherent in all these questions; a domain needs to be able to establish trust, via cross-certification, with other domains. Each domain may opt to use its own ad hoc routing method or a global hierarchy can be established within which every domain resides, cross-certified with at least one other domain (see Figure 3).
Retrieval of a certificate from within the local domain is a straightforward operation. The client contacts the CS, outlining the details, either subject name or serial number, of the desired certificate. The CS checks the request; if valid, it searches the certificate database and returns the certificate, if found. The client must then verify the certificate for authenticity using the CA's public key to verify the digital signature on the certificate. This is the expensive operation, decrypting the signature using the public key.
A subsequent check on a certificate with a valid signature is to check whether it has been revoked. The client must contact the CRS, requesting a copy of the latest CRL. Once it receives a copy of the CRL the client must verify the signature on the CRL using the CA's public key. If the CRL is valid then the client searches for the certificate serial number in the CRL. If the serial number is found, then the certificate has been revoked and may only be usable for decrypting data encrypted (or verifying data signed) by the certificate owner before the certificate was revoked.
Retrieving a certificate from a remote domain yields a chain of certificates corresponding to the path of cross-certification of CAs/domains through the hierarchy and the desired certificate. Validating the certificate chain requires that each certificate's digital signature is verified with the issuing CA's public key. This process begins with the first certificate in the chain, which is generated by the local CA, yielding the public key of the issuing CA of the next certificate in the chain. The process continues, validating certificates in the chain using previous certificates in the chain until the final certificate can be verified. If the certificate chain is 10 certificates long then 10 digital signatures need to be verified, and possibly 10 CRLs retrieved and verified, totalling up to 20 digital signature verifications and quite a delay.
It is obvious from this example, that certificate chains need to be kept as short as possible to ensure timely retrieval. This hinges upon a domain hierarchy which optimises the hop distance between domains.
Trust is the primary factor and it must be maintained to ensure the integrity of each domain. Cross-certification occurs in much the same manner as client certification, except that there must be higher assurance of authenticity of each party. Typically, security administrators of each domain must meet, agree on policies and other details, then exchange CA public keys for certificate creation.
As with certification, revocation may occur on-line or off-line; however, unlike certification, either method can be trusted. Clients requesting revocation of their own certificate must digitally sign the request which contains the certificate. Since revocation requires generation of a CRL signed by the CA, the CA is the revocation agent to which all revocation requests are sent. The CA can verify the revocation request and also the certificate within the request. If both are valid then the certificate details are added to the most recent CRL and the CRL is signed by the CA and issued to the CRS.
In the process of administering the local domain, the administrator may find reason to revoke a certificate. This may be due to suspicion of compromise by disclosure or attack, certificate expiration, or possibly that the client owning the certificate has left the company. In such situations, the administrator must have the authority to revoke certificates.
The CRL is maintained by the CA and, as each revocation occurs, an entry is added to the list. As the CA's domain ages, the CRL grows, listing all revoked certificates. It is obvious that, as time goes by, the CRL may become quite large especially in a domain with a large client base and high turnover of certificates. As a mechanism, CRLs are the most obvious solution to the problem of storing and relaying revocation information; however, obesity of CRLs needs to be addressed.
Delta CRLs have been proposed as a solution to the CRL problem. In this idea, CRLs are issued over short timeframes, with each CRL adding to the revocation database comprised of all previous CRLs. Hence, each CRL issued is effectively a delta or update of previous revocation information. Delta CRLs have achieved some popularity in the PKI world; however, there are substantial arguments against their use:
CRNs are, however, not a problem for all the troubles of revocation. Under this proposal, certificates could not be cached by clients or within domain CSs because, while cached, they may be revoked. This means increased load on certificate retrieval, but reduced load on CRL retrieval, and implementation would depend on the trade-off between these two loads. Of course, fetching and verifying a certificate would require only the single network operation and a local check for the revocation notice within the certificate.
As domains fit into a larger hierarchy, so too does policy. Default policy would flow through the 'root' of the hierarchy down into subordinate domains - from parent domain to child domain. Policy specified locally within a domain would override any policy default inherited from higher in the domain hierarchy and, where no local policy exists, inherited policy would be used.
If the negotiation process cannot be resolved, in instances where policies are mutually exclusive, then the options of an unsecured connection or termination of the session should be provided.
This design and implementation identified a number of outstanding and quite difficult issues which impact upon both the design and implementation of an infrastructure for public key technology. Interdomain hierarchy, certificate retrieval and trust are problems which, although theoretically solved, remain to be proven in practice. We hope to use the DSTC PKI model to answer these questions from an operational perspective.
The proposed structure of CA, CS and CRS, where the CA is the trusted third party, maintains a very localised trusted computing base and minimises the risk of compromise. Off-line certification and secured communications channels also add to the security of the servers within the domain unit. Interdomain security is maintained through limited access via the CS and cross-certification between the CAs of trusting domains.
Policy remains an unresolved problem. Two main problems exist: how policy is managed within the PKI (including policy propagation and inheritance) and how policy is specified. The former has a variety of proposed solutions such as local domain-based policy or policy CAs which specify default policy within the PKI hierarchy. The latter is a question of what language is satisfactory for specifying policy. Subsequently, this begs the question of what aspects of the PKI can and should be specified by policy and what policy choices different types of organisations might wish to specify.
Return to Conference Proceedings