Public key cryptography standards (PKCSs) are widely used methods for encrypting sensitive data to make it unreadable. There are 11 active PKCSs, which define public key and private key pairs. The PKCS (and cryptography broadly) are key considerations for regulatory compliance.
Want to learn more about PKCS? Schedule a free consultation today.
Public Key Cryptography Standards in Cyber Security 101
Cryptography is the art and science of making information unreadable. It “locks” away information so that you need a “key” to read it. This practice predates IT infrastructure by millennia, but it’s an integral part of contemporary IT and security strategy. In particular, public key cryptography is widely used to secure sensitive data against unauthorized access.
To understand public key cryptography standards in cyber security, you’ll need a quick overview of how public key cryptography works. Then, you can appreciate what the 11 active PKCSs are and their implications for regulatory compliance and overall cyberdefense.
A Primer on Cryptography, Public Keys, and Security
Cryptography uses secret information (keys) to encrypt and decrypt text. It creates a cipher, which is a string of information that is illegible unless you have the code to unlock it. In the most basic example, individual letters could be substituted for other characters. Knowing the manner by which they are substituted (the equation or algorithm) would allow you to “unlock” the message.
To make a strong key, you need the system to be hard to guess—ideally, it should look random.
In a cybersecurity context, the codes are orders of magnitude more complex. Keys are typically long, seemingly randomized sequences generated algorithmically to avoid codebreaking.
There may be a single key, or pair of symmetric keys, shared by the sender and recipient of a message—this is called private key cryptography. In contrast, public key cryptography uses pairs of asymmetric keys. There is a public key that senders can use to encode (encrypt) information. These are not necessarily shared with the public, but they may be known by multiple people. Private keys pair with these public keys, enabling recipients to decode the information. They are known to only one person or a tightly controlled set of people.
Cryptography standards like the PKCS dictate how these keys are developed and used.
Breakdown of Currently Active PKCS Standards
The PKCSs are standards for generating public keys and paired private keys. They dictate rules for algorithms and verification for all parts of the encryption and verification process, along with safe storage and shipment of keys and information concerning them. The firm RSA Security began publishing these standards in the 1990s, and there have been 15 in total.
It should be noted that the PKCSs themselves are not industry-wide or government-mandated regulations. They are protocols that may be used to meet compliance or other security needs.
Since their initial publication, certain PKCSs were withdrawn, with their properties absorbed into other standards. Others have been abandoned, with no further engagement. The following 11 PKCSs are the most critical ones to consider when incorporating cryptographic protections.
Request a Free Consultation
PKCS #1: RSA Cryptography Standard
This is the first and most fundamental standard that gives shape to all PKCSs. It establishes the importance of large prime numbers for public key encryption. Namely, because large prime integers are difficult to factor, equations involving them will appear to approximate randomness.
Given this principle, all RSA algorithms are based on the multiplication of prime numbers. From this, PKCS #1 defines “primitive” functions that generate and manipulate keys, including:
- Integer to Octet String Primitive (12OSP)
- Octet String to Integer Primitive (OS2IP)
- RSA Encryption Primitive (RSAEP)
- RSA Decryption Primitive (RSADP)
- RSA Signature Primitive 1 (RSASP1)
- RSA Verification Primitive 1 (RSAVP1)
The general functions do not provide protection on their own; they are the building blocks for elements of strong cryptography (like octets, or eight-byte strings of information). They are adapted into schemes for creating public and private keys with security assured (to a point).
PKCS #1 has undergone changes over the years, incorporating elements of withdrawn standards and adapting to PKCS security vulnerabilities discovered by theorists.
PKCS #3: Diffie-Hellman Key Agreement Standard
This standard provides the basic theoretical underpinning for how private and public keys work in concert. Initially developed in the 1970s, it illustrates how two parties can securely share a private string of information in a public (unsecured) setting without any other listeners or unintended recipients being able to understand what they are saying to each other.
The process involves two communicators agreeing, publicly, on a message, like a string of numbers. The next step is each party selecting a secret, random sequence—this is kept private. Both parties then combine their individual secret and the shared number and share the output with each other publicly. Finally, both parties combine this publicly-shared output with their respective secret, in private, and the final product is a common secret that is mathematically guaranteed to be the same for both recipients and completely illegible to an outside observer.
PKCS #5: Password-based Encryption Standard
Abbreviated to PBKFD1 and 2, these standards apply to protections on passwords, usernames, and other authentication data. In particular, PKBDF2 takes any relatively simple password and makes it significantly harder to crack by applying layers of hashing and coding.
The following inputs work together to create a derived key (DK) in any desired length:
- Password (P) – The chosen password or passphrase, expressed as an octet string
- Salt (S) – A random string of data used for hashing the password (also an octet string)
- Iteration Count (c) – The number of times an operation is performed (a positive integer)
- Intended Length (dkLen) – The final length of the DK (longer is better), in octets
The longer the DK, the more Bits of information it contains. The more bits of information there are, the more computing is required to crack it in a brute force attack. PBKDF2 allows essentially limitless dkLen, which increases the costs of cracking even a single credential exponentially.
PKCS #7: Cryptographic Message Syntax Standard
This standard was built upon the Internet Engineering Task Force’s (IETF) Privacy-Enhanced Mail (PEM) framework. It was then, in turn, adapted into IETF’s Secure/Multipurpose Internal Mail Extensions (S/MIME) standard and CMS standard.
In all its forms, it has dictated secure processes for storing encrypted data. Specifically, it prescribes schemes for signing, hashing, and authenticating information for storage purposes.
These are all certificate-based systems, closely related to PKCS #10 (see below).
PKCS #8: Private-Key Information Syntax Standard
This standard concerns storage for private keys in particular, along with private-public key pairs, which can be stored under further layers of encryption or not (further) encrypted. Passwords and passphrases stored under PKCS #8 protocols may be encrypted according to PKCS #5.
Secure storage of private keys and private key information (such as the algorithm used to determine or encrypt the private key) is paramount. If information about the private key is compromised, it could lead to security risks for any other entities sharing the (paired) public key.
PKCS #9: Selected Attribute Types
This standard exists to define attributes used in verification and other requests for several PKCSs, notably PKCS #6 (detracted), PKCS #7 (see above), and PKCS #10 (see below). Specifically, it dictates certain qualities that data of this nature needs to have. In particular, it describes methods for protecting information related to individuals’ identifiers, such as names.
This standard is particularly important for organizations that process personally identifiable information (PII). This data is often subject to special regulation based on industry (HIPAA) or location (EU GDPR). PKCS #9 helps ensure these and other requirements are met.
PKCS #10: Certification Request Standard
This is one of the most widely applicable PKCSs. It prescribes formatting rules and other specifications for Certificate Signing Requests (CSR). Individuals send CSRs to certificate authorities (CA) to verify themselves. This allows them to create private key pairs using a public key that they choose, available from the CA or from another provider.
Successful certification means that users accessing a given piece of encrypted information protected by the certificate are who they say they are—and have the authority to access it.
It should be noted that PKCS #10 is not the only accepted kind of CSR.
Other options include the Certificate Request Message Format (CRMF) and Signed Public Key and Challenge (SPKAC) format. For PKCS #10 specifically, the process requires these factors:
- The certification request information (the public key and information about the entity)
- Signature algorithm identifiers (information about the mathematics used in the key)
- Digital signature (authenticating the applicant and preventing fraudulent requests)
PKCS #11: Cryptographic Token Interface
This standard, also called “Cryptoki,” dictates rules, processes, and best practices for cryptographic tokens. Tokens are devices (physical or otherwise) used to access digital resources. Physical examples include keyfobs and other media that store information for near-field communication (NFC), radio frequency identification (RFID), or other means of authentication. Crypto tokens in particular store secret (encrypted) information.
PKCS #11 defines a platform-agnostic application programming interface (API) that works in conjunction with crypto token generators. One common application is smart card processing.
PKCS #12: Personal Information Exchange Syntax Standard
This standard prescribes an archival format for storing private keys alongside their paired public keys. The same format can also be used to share other critical information, such as data pertaining to individuals’ identities, digital signatures, and digital certificates.
The bundles or buckets of encrypted and/or signed information are often stored in “SafeBags.” These can be configured to store larger or smaller amounts of data in compressed and secure formats, according to compliance and other requirements.
PKCS #12 uses an intricate, nesting system of layered complexity applicable to storage or transfer. Its architecture is based on PKCS #8, with additional clearances for integrity.
PKCS #15: Cryptographic Token Information Format Standard
Finally, this standard works alongside (but separate from) PKCS #11. It empowers users to identify themselves to applications irrespective of the Cryptoki or other API. This allows for something akin to certificate-level authentication but using tokens rather than a CSR.
As with certain other PKCSs above, the goal is to achieve greater applicability across disparate system architectures. This is one reason PKCS #15 has been overtaken (in part) by the International Organization for Standardization (ISO) standard ISO/IEC 7816-15:2016.
Public Key Cryptography Standards and Compliance
As noted above, the PKCSs are not regulatory standards. Instead, they are protocols for secure public key cryptography; they guarantee (to an extent) the security of encryptions using them.
Organizations may use these, or other cryptographic measures, to meet compliance needs. For example, PCI DSS compliance requires “strong cryptography” for cardholder data (CHD) in storage and transit. Standards like PBKFD2 can help you determine that strength.
However, in practice, what cryptography you use will be determined by many different factors.
There are different public key requirements and expectations in various industries, but these do not necessarily determine what public key infrastructure (PKI) you’ll use. For example, there is no single crypto public key, although many organizations in crypto and related fields need to achieve Cryptocurrency Security Standard (CCSS) compliance.
Certain industries or business contexts might require the use of a specific PKI, private keys, or overlapping encryption schemes. Working with a security program advisor is the best way to determine which cryptographic protections are best for your organization.
Optimize Your Cryptographic Protections Today
To recap, public key cryptography standards in cyber security are protocols that dictate how to develop, store, and otherwise use public keys. Public key cryptography uses a shared secret in conjunction with a private one to ensure the security of information, and the PKCSs dictate the specific rules, best practices, and other properties that make the whole process work.
These measures come into play for compliance and other cybersecurity practices, but the variety of options available (not to mention the complexity of these protections) can make understanding and implementing encryption difficult. That’s why RSI Security is here.
We help organizations rethink their approach to encryption. Despite the challenges, we know that the right way is the only way to encrypt your data and ensure your stakeholders’ security. To learn more about how we can help, get in touch today!
