This, rather long document, provides a background and in a number of areas details of
the VillageMall public key security services available to VillageMall members. This
information is provided so you can assess the appropriateness of the VillageMall network
trust..
Compare to other offerings... VillageMall is the leader in
Village Security and Trust...
Concepts
VillageMall PKI Components
VillageMall Certificate Authorities
Enabling VillageMall Clients
VillageMall PKI Security Policy
Applications Overview
Cryptography is the science of protecting data. Cryptographic algorithms mathematically combine input plaintext data and an encryption key to generate encrypted data (ciphertext). With a good cryptographic algorithm, it is computationally infeasible to reverse the encryption process and derive the plaintext data starting with only the ciphertext; some additional data, a decryption key, is needed to perform the transformation.
In traditional, secret (or symmetric) key cryptography, the encryption and decryption keys are identical and thus share sensitive data. Parties wishing to communicate with secret-key cryptography must securely exchange their encryption/decryption keys before they can exchange encrypted data.
In contrast, the fundamental property of PK cryptography is that the encryption and decryption keys are different. Encryption with a public key encryption key is a one-way function; plaintext turns into ciphertext easily but the encryption key is irrelevant to the decryption process. A different decryption key (related but not identical to the encryption key) is needed to turn the ciphertext back into plaintext. Thus, for PK cryptography, every user has a pair of keys consisting of a public key and a private key. By making the public key available, it is possible for you to enable others to send you encrypted data that can only be decrypted using your private key. Similarly, you can transform data using your private key in such a way that others can verify it originated with you. This latter capability is the basis for digital signatures, discussed below.
The separation between public and private keys in PK cryptography has allowed the creation of a number of new technologies. The most important of these are digital signatures, distributed authentication, secret key agreement by public key, and bulk data encryption without prior shared secrets.
There are a number of well-known PK cryptographic algorithms. Some, such as RSA (Rivest-Shamir-Adleman) and ECC (Elliptic Curve Cryptography), are general purpose in the sense they can support all of the above operations. Others support only a subset of these capabilities. Some examples include the Digital Signature Algorithm (DSA, part of the U.S. government's Digital Signature Standard, FIPS 186), which is useful only for digital signatures, and Diffie-Hellman (D-H), which is used for secret key agreement.
The following paragraphs briefly describe the principal uses of PK cryptography. These operations are described in terms of two users, Bob and Alice. It is assumed Bob and Alice can exchange information but do not have any prearranged shared secrets between them.
Perhaps the most exciting aspect of public key cryptography is that of creating and validating digital signatures. This is based on a mathematical transform that combines the private key with the data to be signed in such a way that:
Digital signatures are themselves just data, so they can be transported along with the signed data they protect. For example, Bob can create a signed e-mail message to Alice and send the signature along with the message text, providing Alice the information required to verify the message origin. In addition, digital signatures provide a way to verify that data has not been tampered with (either accidentally or intentionally) while in transit from the source to the destination. Because of this, they can be exploited to provide a very high-assurance data integrity mechanism.
One can exploit PK cryptography to provide robust distributed authentication services. Entity authentication guarantees that the sender of data is the entity the receiver thinks it is. One possible method involves the data receiver, Alice, sending a challenge to the data sender, Bob, encrypted with Bob's public key. Bob then decodes this challenge and sends it back to Alice, proving that he has access to the private key associated with the public key Alice used to issue the challenge. An alternative is for Alice to send a plaintext challenge to Bob. Bob then combines the challenge with other information, which is digitally signed. Alice then uses the Bob's public key to verify the signature and prove that Bob has the associated private key. The challenge makes this message unique and prevents replay attacks by a hostile third party. In either case, this is known as a proof of possession protocol because the sender is proving that he has access to a particular private key.
Another feature of PK cryptography is that it permits two parties to agree on a shared secret using public, nonsecure communication networks. Basically, Bob and Alice each generate a random number that will form half of the shared secret key. Bob then sends his half of the secret to Alice encrypted using her public key while Alice sends her half to Bob encrypted with his public key. Each side can then decrypt the message received from the other party, extract the half of the shared secret generated by the other party, and combine the two halves to create the shared secret. Once the protocol is completed, the shared secret can be used for securing other communications.
The fourth major technology enabled by PK cryptography is the ability to encrypt bulk data without the establishment of prior shared secrets. Existing PK algorithms are computationally intensive relative to secret key algorithms. This makes them ill suited for encrypting large amounts of data. To get the advantages of PK cryptography along with efficient bulk encryption, PK and secret key technologies are typically combined.
This is accomplished by first selecting a secret key encryption algorithm and generating a random session key to use for data encryption. If Bob is sending the message, he first encrypts this session key using Alice's public key. The resulting ciphertext key is then sent to Alice along with the encrypted data. Alice can recover the session key using her private key and then use the session key to decrypt the data.
In secret key cryptography, Alice and Bob trust their shared secret key because they mutually agreed on it or exchanged it in a secure manner, and each has agreed to keep it stored securely to prevent access by a malicious third party. In contrast, using PK cryptography, Alice need only protect her private key and Bob his private key. The only information they need to share is each other's public key. They need to be able to identify each other's public key with high assurance, but they need not keep it secret. This ability to trust the association of a public key with a known entity is critical to the use of PK cryptography.
Alice might trust Bob's public key because Bob handed it to Alice directly in a secure manner, but this presupposes that Alice and Bob have had some form of prior secure communication. More likely, Alice has obtained Bob's public key through a nonsecure mechanism (for example, from a public directory), so some other mechanism is needed to give Alice confidence that the public key she holds claiming to be from Bob really is Bob's public key. One such mechanism is based on certificates issued by a certificate authority (CA).
Certificates provide a mechanism for gaining confidence in the relationship between a public key and the entity owning the corresponding private key. A certificate is a particular type of digitally signed statement; the subject of the certificate is a particular subject public key and the certificate is signed by its issuer (holding another pair of private and public keys). Typically, certificates also contain other information related to the subject public key, such as identity information about the entity that has access to the corresponding private key. Thus, when issuing a certificate, the issuer is attesting to the validity of the binding between the subject public key and the subject identity information.
The most common form of certificates in use today is based on the recommendation X.509. This is a fundamental technology used in the VillageMall PKI.
A certificate authority (CA) is simply an entity or service that issues certificates. A CA vouches for the binding between the subject public key ( and the holding of the associated private key) and the subject identity information contained within the certificates it issues. Different CAs may choose to verify that binding by different means, so it is important to understand the authority's policies and procedures before choosing to trust that authority to vouch for public keys.
The fundamental question facing Alice when she receives a signed message is whether she should trust that the signature is valid and was made by whoever claimed to make it. Alice can confirm that the signature is mathematically valid; that is, she can verify the integrity of the signature using a known public key. However, Alice must still determine whether the public key used to verify the signature does in fact belong to the entity claiming to have made the signature in the first place. If Alice does not implicitly trust the public key to be Bob's, she needs to acquire evidence that actually Bob is the holder of the private key associated with the public key.
If Alice can locate a certificate for Bob's public key, issued by a CA Alice implicitly trusts, then Alice can trust that it was Bob that holds the private key associated with the public key. That is, Alice will likely trust she really has Bob's public key, and that it was indeed Bob that used his private key, if she finds a certificate that:
Assuming Alice finds such a certificate for Bob's public key, then she can verify its authenticity using the public key of the issuing CA, Ira. However, Alice is now faced with the same dilemma. How does she know that public key actually belongs to Ira? Alice now needs to find a certificate attesting to the identity of Ira and the binding between Ira and Ira's public key.
Ultimately, Alice will end up constructing a chain of certificates leading from Bob and Bob's public key through a series of CAs and terminating in a certificate issued to someone that Alice implicitly trusts. Such a certificate is called a trusted root certificate because it forms the root (top node) of a hierarchy of public keys/identity bindings that Alice will accept as authentic (see the section "Certificate Hierarchies"). When Alice chooses to explicitly trust a particular certificate, she is implicitly trusting all the certificates issued by that trusted root, as well as all certificates issued by any subordinate CA certified by the trusted certificate.
The set of trusted root certificates that Alice explicitly trusts is the only information that Alice must acquire in a secure manner. That set of certificates bootstraps Alice's trust system and her belief in the public key infrastructure.
Figure 1 presents a top-level view of the components that make up the VillageMall PKI. This is a logical view, and does not imply physical requirements for separate servers; in fact many functions may be combined on a single-server system. The VillageMall CAs support certificate issuance and revocation. They are integrated with Active Directory, which provides CA location information and CA policy and allows certificates and revocation information to be published. In particular, the VillageMall PKI addresses the need for scalable and distributed identification and authentication, integrity, and confidentiality.
Figure 1. VillageMall Public Key infrastructure components
VillageMall supports network authentication and encryption using the industry standard TLS and SSL protocols. Lastly, a smart card interface is supported. These have been used to integrate cryptographic smart cards in an application-independent manner and are the basis for smart card logon support used by the VillageMall network.
VillageMall Certification Services, provides a means for VillageMall to easily establish CAs in support the VillageMall business needs. The VillageMall certificate policy includes identification of the requesting entity and validation that the certificate requested is allowed under the VillageMall certificate policy.
The VillageMall PKI assumes a multiple hierarchical CA model. This was chosen for its scalability, ease of administration, and consistency with a growing number of commercial and third-party CA products, and s management of risk.. The VillageMall CA hierarchy consists of a hierarchy containing multiple CAs with clearly defined parent-child relationships as shown in Figure 3.
In this model, children are certified by parent CA–issued certificates, which bind a CA's public key to its identity and other policy-driven attributes. The CA at the top of a hierarchy is generally referred to as a root CA. The subordinate CAs are often referred to as or issuing CAs. The VillageMall structure has two root CA's and several Regional issuing CA's.
The root CA's are related to the network domains and also to the certificate policy and assurance level.
Figure 3. Certificate authority hierarchies
VillageMall supports both a high and medium certification policy and the associated assurance framework.
The fundamental advantage of this model is that verification of certificates requires trust in only a relatively small number of root CAs. At the same time, it provides flexibility in terms of the cost vs assurance tradeoffs that need to be made. There are several practical reasons for supporting multiple issuing CAs. These include:
Such a CA hierarchy also provides administrative benefits, including:
VillageMall provides a comprehensive set of core services supporting the securing of the VillageMall and its Villagers applications. In the remainder of this section, we examine the core applications services provided by the VillageMall PKI.
Use of PK technology is dependent upon the ability to generate and manage keys for one or more PK algorithms. Mechanisms for storing key material are dependent on the selected Crypto Service Providers. Standard Browser's such as Microsoft-provided CSPs store key material in an encrypted form on a per-user or per-machine basis. In addition, they support control over public key pair exportability and usage control. The former controls private key export from the CSP; the latter determines user notification behavior when an application attempts to use the private key. Other CSPs may implement different mechanisms. For example, smart card CSPs store the public key pair in the smart card tamper-resistant hardware and generally require entry of a PIN code to access operations involving the private key. VillageMall CA services allow you to set these as you require. VillageMall Tokens are required for the protection and storage of all private keys. VillageMall supports the generation of private keys within a VillageMall Token.
Key recovery is useful only when applied to keys used in the encryption of persistent data. For PK-based applications, this usually implies an entity's key exchange keys. There is questionable value, and considerable danger, in archiving identification or digital-signature private keys, because their only practical use would be for impersonation of the private key owner. VillageMall does not support Key recovery.
As discussed previously, practical use of PK-based technology generally relies on certificates to bind public keys to known entities. The VillageMall PKI supports certificate enrollment to the network CA's. Enrollment support is implemented in a transport-independent manner and is based on use of industry-standard PKCS-10 certificate request messages and PKCS-7 responses containing the resulting certificate or certificate chain. At this time, certificates supporting RSA keys and signatures, Digital Signature Algorithm (DSA) keys and signatures, and Diffie-Hellman keys are supported.
Support for PKCS-10 and PKCS-7 messages is provided by a Microsoft-supplied enrollment control. The enrollment process is assumed to be asynchronous, and the enrollment control provides state management to match issued certificates against pending requests. This provides a means of creating an internal binding between the certificate, the CSP that generated the key pair, and the key pair container name.
The PKI supports multiple enrollment methods including Web-based enrollment, an enrollment wizard, and policy driven auto-enrollment, which occurs as part of a user's logon processing.
Certificate renewal is conceptually similar to enrollment, but takes advantage of the trust relationship inherent in an existing certificate. Renewal assumes the requesting entity wants a new certificate with the same attributes as an existing, valid certificate, but with extended validity dates. A renewal may use the existing public key or a new public key.
Renewal is of advantage primarily to the CA. A renewal request can presumably be processed more efficiently since one need not re-verify the existing certificate attributes. Renewal is currently supported in the VillageMall PKI for automatically enrolled certificates. For other mechanisms, a renewal is treated as a new enrollment request.
Industry-standard message protocols for certificate renewal are not yet defined, but are included in the IETF PKIX CRS draft. Once these standards are ratified, Microsoft plans to implement the associated message formats.
Within the PKI, cryptographic keys and associated certificates are stored and managed by the Crypto subsystem. As noted above, keys are managed by CSPs and certificates are managed by the Crypto certificate stores.
Roaming in the context of this paper means the ability to use the same PK-based applications on different physical machines within the VillageMall Network environment. The principal requirement is to make a user's cryptographic keys and certificates available wherever the user logs on.
Certificates tend to be long-lived credentials and there are a number of reasons why these credentials may become untrustworthy prior to their expiration. Examples include:
PK-based functionality assumes distributed verification in which there is no need for direct communication with a central trusted entity that vouches for these credentials. This creates a need for revocation information that can be distributed to individuals attempting to verify certificates.
The need for revocation information, and its timeliness, is dependent upon the application. To support a variety of operational scenarios, the VillageMall PKI incorporates support of industry-standard Certificate Revocation Lists (CRLs). VillageMall CAs support certificate revocation and CRL publication. Villager's clients and VillageMall servers can fetch this information, to use when verifying certificates.
The principal client trust concern when using PK-based functionality is the trust associated with certificate verification. This is generally based on the trust associated with the CA that issued the certificate. As discussed previously, the PKI assumes a rooted CA hierarchy in which the control of trust is based on decisions concerning root CAs. If a given end-entity certificate can be shown to chain to a known trusted root CA, and if the intended certificate usage is consistent with the application context, then it is considered valid. If either of these conditions is not true, then it is considered invalid.
Within the PKI, users may make trust decisions that affect only themselves. They do this by installing or deleting trusted root CAs and configuring associated usage restrictions through the certificate-management administrative tools.
Security policies can be applied to sites, domains, or organizational units (OUs), and affect the associated security groups of users and computers. PK security policy is simply one aspect of the overall VilageMall security policy, and is integrated into this structure. It provides a mechanism to centrally define and manage policy while enforcing it globally. The most significant aspects of PK security policy are discussed below.
Trust in root CAs may be set by policy to establish trust relationships used by domain clients in verifying PK certificates. The set of trusted CAs is configured using the Group Policy Editor. It can be configured on a per-machine basis and will apply globally to all users of that machine.
In addition to establishing a root CA as trusted, the administrator can set usage properties associated with the CA. If specified, these restrict the purposes for which the CA-issued certificates are valid. Restrictions are specified based on object identifiers (OIDs) as defined for ExtendedKeyUsage extensions in the IETF PKIX Part 1 draft. Currently, these provide a means of restricting usage to any combination of the following:
As part of the overall PKI integration with VillageMall, policy mechanisms have been defined to support an automated certificate enrollment process. This is controlled by two key elements: certificate types, and auto-enrollment objects. These are integrated with the Group Policy Object, and may be defined on a site, domain, machine, or user basis.
Certificate types provide a template for a certificate and associate it with a common name for ease of administration. The template defines elements such as naming requirements, validity period, allowable CSPs for private key generation, algorithms, and extensions that should be incorporated into the certificate. The certificate types are logically separated into machine and user types and applied to the policy objects accordingly. Once defined, these certificate types are available for use with the auto-enrollment objects and certificate enrollment wizard.
This mechanism is not a replacement for the enterprise CA issuing policy, but is integrated with it. The CA service receives a set of certificate types as part of its policy object. These are used by the Enterprise Policy Module to define the types of certificates the CA is allowed to issue. The CA rejects requests for certificates that fail to match these criteria.
The auto-enrollment object defines policy for certificates that an entity in the domain should have. This can be applied on a machine and user basis. The types of certificates are incorporated by reference to the certificate type objects, and may be any defined type. The auto-enrollment object provides sufficient information to determine whether an entity has the required certificates, and to enroll for those certificates with an enterprise CA if they are missing. The auto-enrollment objects also define policy on certificate renewal. This can be set by an administrator to occur in advance of certificate expiration, supporting long-term operation without direct user action. The auto-enrollment objects are processed, and any required actions taken, whenever policy is refreshed (logon time, and so on).
Smart card logon (Also see the upcoming section "Smart Card Logon" in the "Applications Overview" section of this document.) is controlled by policy associated with the user object in a manner analogous to password policy. Policy may be set either to enable smart card logon, in which case password-based logon may still be used, or to enforce smart card logon. In the latter case, protection against unauthorized access to the account is significantly stronger. It does mean, however, that users will be unable to log on if they forget their smart card or attempt to use a machine lacking a smart card reader.
This section provides an overview of significant applications that currently take advantage of PK-based functionality. It is intended as an introduction to the ways you can utilize an investment in PKI to solve real-world business needs.
The Web has rapidly become a key element in creating and deploying solutions for the effective exchange of information on a worldwide basis. In particular, growth in its use for business purposes has been dramatic. For many uses, security is a key consideration. Notably:
The Secure Sockets Layer (SSL) and the emerging IETF standard Transport Layer Security (TLS) protocols play an important role in addressing these needs. SSL and TLS are flexible security protocols that can be layered on top of other transport protocols. They rely on PK-based authentication technology and use PK-based key negotiation to generate a unique encryption key for each client/server session. They are most commonly associated with Web-based applications and the HTTP protocol (referred to as HTTPS).
Taking full advantage of the SSL and TLS protocols requires both clients and servers to have identification certificates issued by mutually trusted CAs, allowing the parties to authenticate each other. In this mode, certificates are exchanged along with data that proves possession of the corresponding private key. Each side can then validate the certificate and verify possession of the private key using the certificate's public key. The identifying information included in the certificate can then be used to make supplemental access control decisions. For example, the client can decide whether the server is someone it wishes to conduct business with and the server can decide what data the client will be allowed access.
The VillageMall PKI integrates support for the latter decisions as a standard feature of Windows Servers. User certificates can be mapped on a one-to-one or many-to-one basis against security principals (User objects) in the Active Directory. This is advantageous for services in that they can utilize the identical access control mechanism independent of the client authentication mechanism used (PK or Kerberos).
Once the client and server have authenticated each other, they can proceed to negotiate a session key and begin communicating securely. SSL and TLS are also often employed in a mode that doesn't require client authentication. Use of mutual authentication is recommended in the enterprise environment, however, because it allows you to make use of the access control mechanisms. Also, the PKI significantly simplifies certificate enrollment and management, reducing the burden on the client.
The growing use of the Internet has driven reliance on downloaded active content such as Windows-based applications, ActiveX controls, and Java applets. The result has been a heightened concern for the safety of such downloads, as they often occur as a side effect of Web scripts without any specific user notification.
Authenticode technology allows software publishers to digitally sign any form of active content, including multiple-file archives. These signatures may be used to verify both the publishers of the content and the content integrity at download time. This verification infrastructure scales to the worldwide base of users of Windows by relying on a hierarchical CA structure in which a small number of commercial CAs issue software-publishing certificates. The VillageMall PKI issues Authenticode certificates to internal developers/contractors and allows any Villager to verify the origin and integrity of downloaded applications.
VillageMall introduces PK-based smart card logon for VillageMall strong authentication.
In operation, your PC will recognize a smart card insertion event as an alternative to the standard CTRL + ALT + DEL secure attention sequence to initiate a logon ( requires Windows 2000 workstation). You are then prompted for the smart card PIN code, which controls access to operations with the private key stored on the smart card. In this system, the smart card also contains a copy of the user's certificate (issued by VillageMall CA).
IPSec defines protocols for network encryption at the IP protocol layer. IPSec does not require PK-based technology and can use shared secret keys, communicated securely through an out-of-band mechanism, at the network endpoints for encryption. The IETF IPSec working group recognized, however, that PK-based technology offers a practical solution to create a scalable distributed trust architecture, in particular, one in which IPSec devices can mutually authenticate each other and agree upon encryption keys without reliance on prearranged shared secrets. VillageMall uses IPSec and PK certificates to create a Virtual VillageMall network, that can be securely dispersed throughout the nation.
All of this provides you, your customers, suppliers and employees, the most secure environment available to conduct business.
