Is Your Organization Updated with the Public Key Cryptography Standards?

Cryptographic standards have two important goals: to make different implementations interoperable and to avoid various known errors in typical schemes. In this blog, we discussed the Public Key Cryptography Standard (PKCS), which has had a significant impact on the use of public-key encryption in practice. The PKCS standard is a set of standards called PKCS 1 to 15.

These standards cover RSA encryption, RSA signature, password-based encryption, encrypted message syntax, private key information syntax, selected object category and attribute type, authentication request syntax, encryption token interface, personal information exchange syntax, and encrypted token information grammar. RSA Laboratories publishes the PKCS standard.

Although RSA Laboratories solicits comments and suggestions from the public on the PKCS standard, RSA Laboratories reserves the exclusive power to decide all aspects of the PKCS standard. PKCS has become the basis for many other standards, such as S/MIME.

Public key cryptography is based on an asymmetric cryptographic algorithm, which uses two related keys, a public key, and a private key; the nature of these two keys is that, given the public key, the private key is derived. It is computationally infeasible. Users publish their public keys in public directories, such as LDAP directories, and leave their private keys to themselves. 

Depending on the purpose of the algorithm, there are public-key encryption and decryption algorithms and signature algorithms. Encryption algorithms can be used to encrypt data using a public key (for example, a symmetric key) so that only the recipient with the corresponding private key can decrypt the data.

Typical public key encryption algorithms are RSA and ECIES (Elliptic Curve Integrated Encryption Scheme, see SECG 2000). The signature algorithm is combined with the message digest algorithm, which can convert messages of any length using the private key into a signature. In this way, without knowing the private key, the same signature cannot be found computationally.

The message with the default signature can be found, or see the signature of a specific message. Anyone with the corresponding public key can verify the validity of the signature. Typical public key digital signature algorithms are RSA, DSA, and ECDSA.

PKCS Specifications

PKCS Standards

PKCS #1: RSA Cryptography Standard

PKCS #1 v2.1 provides standards for implementing RSA algorithm-based public key cryptographic encryption schemes and digital signature schemes with appendix. It also defines corresponding ASN.1 syntax for representing keys and for identifying the techniques.

The security of the RSA algorithm is believed to be based on the hardness of factoring the product of large prime numbers. In PKCS #1 v2.1, a multi-prime RSA scheme is introduced. Multiprime RSA means that the modulus isn’t the product of two primes but more than two primes. This is used to increase the performance of RSA cryptographic primitives.

PKCS #3 (outdated): Diffie-Hellman Key Agreement Standard

PKCS #3 v1.4 describes a method for implementing the Diffie-Hellman key agreement, whereby two parties can agree upon a secret key known only to them. PKCS #3 is superseded by the modern treatment of key establishment schemes specified in IEEE 1363a (2003), ANSI 9.42, ANSI X9.44, ANSI X9.63, etc.

PKCS #5: Password-Based Cryptography Standard

In many applications of public-key cryptography, user security is ultimately dependent on one or more secret text values or passwords. For example, a user’s private key is usually encrypted with a password, and the encrypted private key is kept in storage devices. However, there are two fundamental problems regarding password application:

1. A password is not directly applicable as a key to any conventional cryptosystem
2. Passwords are often chosen from a relatively small space.

Thus special care is required to defend against search attacks. PKCS #5 provides a general mechanism to achieve enhanced security for password-based cryptographic primitives, covering key derivation functions, encryption schemes, message-authentication schemes, and ASN.1 syntax identifying the techniques.

PKCS #6 (Historical): Extended-Certificate Syntax Standard

When PKCS #6 was drafted, X.509 was in version 1.0, and no extensions component was defined in the certificate. An X.509 v3 certificate can contain information about a given entity in the extensions component. Since the introduction of X.509 v3, the status of PKCS #6 is historic.

PKCS #7 and RFC 3369: CMS or Cryptographic Message Syntax

PKCS #7 has been superseded by IETF RFC 3369 (Housley 2002): cryptographic message syntax (CMS), which is the basis for the S/MIME specification. CMS defines the syntax used to digitally sign, digest, authenticate, or encrypt arbitrary message content. In particular, CMS describes an encapsulation syntax for data protection. The syntax allows multiple encapsulations; one encapsulation envelope can be nested inside another.

Likewise, one party can digitally sign some previously encapsulated data. In the CMS syntax, arbitrary attributes, such as signing time, can be signed along with the message content, and other details, such as countersignatures can be associated with a signature. A variety of architectures for certificate-based key management (e.g., the one defined by the IETF PKIX working group) are supported in CMS.

PKCS #8: Private-Key Information Syntax Standard

The security of the public key cryptosystem is entirely dependent on the protection of the private keys. Generally, the private keys are encrypted with a password and stored in some storage medium. It is essential to have a standard to store private keys to move private keys from one system to another system without any trouble.

PKCS #8 v1.2 describes a syntax for private-key information, including a private key for some public-key algorithms, a set of attributes, and a syntax for encrypted private-key information. A password-based encryption algorithm (e.g., one of those described in PKCS #5) could be used to encrypt the private-key information.

PKCS #9: Selected Object Classes and Attribute Types

To support PKCS-defined attributes (e.g., to store PKCS attributes in a directory service) in directory systems based on LDAP and the X.500 family protocols, PKCS #9 v2.0 defines two auxiliary object classes, pkcsEntity, and naturalPerson. PKCS attributes could be packaged into these two object classes and be exported to other environments such as LDAP directory systems.

PKCS #9 v2.0 also defines some new attribute types and matching rules that could be used in different PKCS standards. For example, it defines challengePassword and extensionRequest attribute types to be used in PKCS #10 attribute field, and it describes some attribute types to be used in PKCS #7 (CMS) signedAttrs, unsignedAttrs, unprotectedAttrs, authAttrs, and unauthAttrs fields

PKCS #10: Certification Request Syntax Standard

PKCS #10 v1.7 specifies syntax for certificate request. When one entity wants to get a public key certificate, the entity constructs a certificate request. It sends it to a certification authority, which transforms the request into an X.509 public-key certificate.

A certification authority fulfills the request by authenticating the requesting entity and verifying the entity’s signature, and, if the request is valid, constructing an X.509 certificate from the distinguished name and public key, the issuer name, and the certification authority’s choice of a serial number, validity period, and signature algorithm.

Suppose the certification request contains any PKCS #9 attributes. In that case, the certification authority may also use the values in these attributes and other information known to the certification authority to construct X.509 certificate extensions. PKCS #10 does not specify the forms that the certification authority returns the new certificate.

PKCS #11: Cryptographic Token Interface Standard

PKCS #11 v2.20 specifies an application programming interface (API), called “Cryptoki”, to devices that hold cryptographic information and perform cryptographic functions. Cryptoki, pronounced “crypto-key” and short for “cryptographic token interface”, follows a simple object-based approach, addressing the goals of technology independence (any device) and resource sharing (multiple applications accessing multiple devices), presenting to applications a standard, logical view of the device called a “cryptographic token”.

Cryptoki was intended from the beginning to be an interface between applications and all kinds of portable cryptographic devices, such as those based on smart cards, PCMCIA cards, and intelligent diskettes. The primary goal of Cryptoki was a lower-level programming interface that abstracts the details of the devices and presents to the application a standard model of the cryptographic device, called a “cryptographic token”.

PKCS #12: Personal Information Exchange Syntax Standard

PKCS #12 v1.0 describes a transfer syntax for personal identity information, including private keys, certificates, miscellaneous secrets, and extensions. Machines, applications, browsers, Internet kiosks, and so on that support this standard will allow users to import, export, and exercise a single set of personal identity information. PKCS #12 can be viewed as building on PKCS #8 by including essential but ancillary identity information and private keys and instituting higher security through public-key privacy and integrity modes.

PKCS #15: Cryptographic Token Information Syntax Standard

Cryptographic tokens, such as Integrated Circuit Cards (or IC cards), are intrinsically secure computing platforms ideally suited to providing enhanced security and privacy functionality to applications. They can handle authentication information such as digital certificates and capabilities, authorizations, and cryptographic keys.

Furthermore, they can provide secure storage and computational facilities for sensitive information such as private keys and key fragments. At the same time, many of these tokens provide an isolated processing facility capable of using this information without exposing it within the host environment where it is at potential risk from malicious code (viruses, Trojan horses, and so on). Unfortunately, using these tokens for authentication and authorization purposes has been hampered by the lack of interoperability.

First, the industry lacks standards for storing a common format of digital credentials (keys, certificates, etc.) on them. This has made it difficult to create applications that can work with credentials from various technology providers. Second, mechanisms to allow multiple applications to share digital credentials effectively have not yet reached maturity.

Resources

Public Key Cryptography Standards

RFC 2986

PKCS