Community hub
0 subscribers7 pages, 0 posts
Recent from talks
All channels
Be the first to start a discussion here.
Be the first to start a discussion here.
Be the first to start a discussion here.
Be the first to start a discussion here.
Contribute something
Welcome to the community hub built to collect knowledge and have discussions related to PKCS 12.
Nothing was collected or created yet.
PKCS 12
View on Wikipediafrom Wikipedia
| PKCS #12 | |
|---|---|
| Filename extension | .p12, .pfx |
| Internet media type |
application/x-pkcs12 |
| Uniform Type Identifier (UTI) | com.rsa.pkcs-12[1] |
| Developed by | RSA Security |
| Initial release | 1996 |
| Latest release | PKCS #12 v1.1 27 October 2012 |
| Type of format | Archive file format |
| Container for | X.509 public key certificates, X.509 private keys, X.509 CRLs, generic data |
| Extended from | Microsoft PFX file format |
In cryptography, PKCS #12 defines an archive file format for storing many cryptography objects as a single file. It is commonly used to bundle a private key with its X.509 certificate or to bundle all the members of a chain of trust.
A PKCS #12 file may be encrypted and signed. The internal storage containers, called "SafeBags", may also be encrypted and signed. A few SafeBags are predefined to store certificates, private keys and CRLs. Another SafeBag is provided to store any other data at individual implementer's choice.[2][3]
PKCS #12 is one of the family of standards called Public-Key Cryptography Standards (PKCS) published by RSA Laboratories.
The filename extension for PKCS #12 files is .p12 or .pfx.[4]
These files can be created, parsed and read out with the OpenSSL pkcs12 command.[5]
Relationship to PFX file format
[edit]PKCS #12 is the successor to Microsoft's "PFX";[6] however, the terms "PKCS #12 file" and "PFX file" are sometimes used interchangeably.[4][5][7]
The PFX format has been criticized for being one of the most complex cryptographic protocols.[7]
Normal usage
[edit]The full PKCS #12 standard is very complex. It enables buckets of complex objects such as PKCS #8 structures, nested deeply. But in practice it is normally used to store just one private key and its associated certificate chain.[citation needed]
PKCS #12 files are usually created using OpenSSL, which only supports a single private key from the command line interface. The Java keytool can be used to create multiple "entries" since Java 8, but that may be incompatible with many other systems.[8] As of Java 9 (released 2017-09-21), PKCS #12 is the default keystore format.[9][10]
A simpler, alternative format to PKCS #12 is PEM which just lists the certificates and possibly private keys as Base 64 strings in a text file.
GnuTLS's certtool may also be used to create PKCS #12 files including certificates, keys, and CA certificates via --to-p12. However, beware that for interchangeability with other software, if the sources are in PEM Base64 text, then --outder should also be used.
References
[edit]- ^ "pkcs12". Apple Developer Documentation: Uniform Type Identifiers. Apple Inc. Archived from the original on 2023-05-28.
- ^
"PKCS #12: Personal Information Exchange Syntax Standard". RSA Laboratories. Archived from the original on 2017-04-17.
This standard specifies a portable format for storing or transporting a user's private keys, certificates, miscellaneous secrets, etc.
- ^ "PKCS 12 v1.0: Personal Information Exchange Syntax" (PDF). RSA Laboratories. 1999-06-24. Archived from the original (PDF) on 2020-01-16. Retrieved 2020-01-16.
- ^ a b Michel I. Gallant (March 2004). "PKCS #12 File Types: Portable Protected Keys in .NET". Microsoft Corporation. Archived from the original on 2023-06-06. Retrieved 2013-03-14.
All Windows operating systems define the extensions .pfx and .p12 as Personal Information Exchange, or PKCS #12, file types.
- ^ a b "openssl-cmds: pkcs12". OpenSSL Project. 2019. Archived from the original on 2023-06-06. Retrieved 2020-01-16.
The pkcs12 command allows PKCS#12 files (sometimes referred to as PFX files) to be created and parsed.
- ^ Peter Gutmann (August 2002). "Lessons Learned in Implementing and Deploying Crypto Software" (PDF). The USENIX Association. Archived (PDF) from the original on 2023-06-06. Retrieved 2020-01-16.
In 1996 Microsoft introduced a new storage format [...] called PFX (Personal Information Exchange) [...] it was later re-released in a cleaned-up form as PKCS #12
- ^ a b Peter Gutmann (1998-03-12). "PFX - How Not to Design a Crypto Protocol/Standard". Archived from the original on 2023-07-10. Retrieved 2020-01-16.
- ^ Kai Kramer (2016-06-05). "p12 files don't show root and sub CA certificates #35".
There exists a general problem when the extremely flexible PKCS#12 format is pushed into the keystore API. [...] 2.16.840.1.113894.746875.1.1: <Unsupported tag 6>
- ^ "JEP 229: Create PKCS12 Keystores by Default". OpenJDK JEPs. Oracle Corporation. 2014-05-30. Archived from the original on 2023-06-08.
- ^ Ryan, Vincent (2014-05-30). "Bug JDK-8044445: Create PKCS12 Keystores by Default". JDK Bug System. Archived from the original on 2023-02-06.
External links
[edit]- RFC 7292 - PKCS #12: Personal Information Exchange Syntax v1.1
- "PKCS #12: Personal Information Exchange Syntax Standard". RSA Laboratories. Archived from the original on 2017-04-17.
This standard specifies a portable format for storing or transporting a user's private keys, certificates, miscellaneous secrets, etc.
- Overview about PKCS#12 capabilities, usage, implementations, history and future: Ryan Hurst and Yury Strozhevsky (2015-12-02). "The PKCS#12 standard needs another update". Archived from the original on 2017-03-03.
PKCS 12
View on Grokipediafrom Grokipedia
Overview
Definition and Purpose
PKCS #12, also known as Public-Key Cryptography Standards #12, is a standardized file format designed for the secure storage and transportation of personal identity information in cryptographic systems.[1] It serves as a container for personal information exchange (PFX), encapsulating X.509 certificates, private keys, and optional elements such as secret keys or certificate chains within a single file.[1] This format ensures that sensitive cryptographic material can be bundled together for portability across different platforms and applications.[8] The primary purpose of PKCS #12 is to facilitate the secure export, import, and backup of private keys alongside their associated public certificates in an encrypted container, typically identified by the .p12 or .pfx file extensions.[1] By providing a password-protected mechanism, it addresses the need for a portable and protected vessel in asymmetric cryptography workflows, allowing users to transfer credentials without exposing them to interception or unauthorized access.[1] This enables straightforward management of digital identities while maintaining confidentiality and integrity during transit.[4] In the context of public-key infrastructure (PKI), PKCS #12 plays a crucial role in applications such as SSL/TLS certificate management, where it bundles server private keys and certificates for secure web server configurations.[8] As part of the broader PKCS family of standards—originally developed by RSA Security and later adopted by the IETF—it evolved to support robust credential handling in distributed systems.[4]Key Components
A PKCS #12 file is structured around the AuthenticatedSafe construct, which serves as the top-level container organizing personal identity information into a sequence of securely protected bags. The AuthenticatedSafe consists of a sequence of ContentInfo objects, each with a content type of data for unencrypted SafeContents, signedData for SafeContents protected by public-key signatures, or envelopedData for SafeContents enveloped with public-key encryption (though the latter is not recommended for new applications), enabling flexible bundling of cryptographic elements while maintaining data integrity and confidentiality. Password-based protection is typically applied to individual SafeBags or via a top-level message authentication code (MAC).[9] At the core of this organization are SafeContents, defined as a SEQUENCE OF SafeBag elements, which encapsulate certificates, private keys, and related items into modular units for efficient storage and transfer within the AuthenticatedSafe. Private keys are typically housed in an EncryptedPrivateKeyInfo structure, which shrouds the key material according to PKCS #8 specifications to facilitate secure key export. Public certificates are stored in CertBag structures, which support multiple certificate types identified by object identifiers (OIDs), such as OID {pkcs-9 22 1} for X.509 certificates, allowing interoperability across different certificate formats.[10][11][12] Each SafeBag is distinctly identified by an OID specifying its type—examples include {pkcs-12 10 1} for KeyBag (unencrypted private keys) and {pkcs-9 22} for CertBag—enabling parsers to process the contents appropriately and ensuring structured data organization. Optional elements enhance this framework by including certificate chains for validation paths, Certificate Revocation Lists (CRLs) for status checks, and secret sharing keys for multi-party scenarios, all integrated as additional bags without altering the core sequence.[13][14][15] The entire structure is encoded using Abstract Syntax Notation One (ASN.1) in Distinguished Encoding Rules (DER) format, producing a compact binary file where OIDs precisely delineate component boundaries and types, thus supporting reliable interchange in public key infrastructure (PKI) environments.[16]History and Development
Origins in PKCS Standards
PKCS #12 originated as part of the Public-Key Cryptography Standards (PKCS) suite, developed by RSA Laboratories starting in the early 1990s to standardize cryptographic primitives and promote interoperability in public-key cryptography implementations.[4] The PKCS series addressed the need for consistent formats and algorithms across diverse systems, fostering widespread adoption of public-key technologies in secure communications.[17] PKCS #12 specifically built upon earlier standards like PKCS #7, which defined cryptographic message syntax for signed and enveloped data but did not support private key storage or transport.[1] To fill this gap, PKCS #12 was designed as a personal information exchange syntax, enabling the secure bundling and transfer of private keys, X.509 certificates, and related secrets in a single, portable file format.[3] This extension was motivated by the limitations of PKCS #7 in handling complete user identities, particularly for applications requiring private key export without compromising security.[1] PKCS #12 was first published as version 1.0 in June 1999 by RSA Laboratories (a division of RSA Security, Inc.), evolving from Microsoft's Personal Information Exchange (PFX) format introduced in 1996.[3] Development involved collaboration with industry leaders, including contributions from Microsoft and Netscape engineers such as Dan Simon and Jim Spring, to ensure compatibility with Microsoft’s CryptoAPI and Netscape’s certificate management systems.[1] This unified approach met pressing needs for interoperable formats that could facilitate secure identity exchange across platforms in emerging networked environments.[3]Standardization and Revisions
PKCS #12 was initially standardized by RSA Laboratories as part of their Public-Key Cryptography Standards (PKCS) suite, with Version 1.0 published in June 1999 to define a syntax for exchanging personal identity information, including private keys and certificates.[18] This version established the core file format but relied on older cryptographic primitives, such as single-iteration password-based key derivation and limited hashing options primarily based on MD5 and SHA-1.[1] In response to evolving security needs and the desire for open maintenance, RSA Laboratories transferred change control of the PKCS #12 standard to the Internet Engineering Task Force (IETF) in the early 2010s, enabling broader community input and updates.[1] The IETF adopted and republished the specification as an informational RFC in July 2014, designated RFC 7292, which corresponds to PKCS #12 Version 1.1 (originally drafted by RSA in December 2012) and incorporates a technical corrigendum for ASN.1 syntax fixes.[19] This republication marked the formal IETF involvement, ensuring the standard's alignment with modern cryptographic practices while maintaining backward compatibility.[20] The primary revisions in RFC 7292 focused on enhancing security against known vulnerabilities in earlier iterations, such as susceptibility to brute-force attacks due to weak key derivation. It introduced support for stronger hash algorithms, including SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224, and SHA-512/256, for use in message authentication codes (MACs) and key derivation, replacing or supplementing the previously dominant SHA-1.[21] For password-based key derivation in privacy modes, the update recommends the use of PBKDF2 as defined in PKCS #5 Version 2.1, which employs a pseudorandom function (PRF) like HMAC-SHA and higher iteration counts to resist dictionary and brute-force attacks, deprecating simpler, single-iteration methods from Version 1.0.[22] Additionally, it deprecates the default iteration count of 1 in the MacData construct for integrity modes and removes low iteration examples like 1024, urging implementers to follow NIST SP 800-132 guidelines for robust protection.[23] While legacy encryption algorithms such as 40-bit RC2-CBC remain permissible for interoperability, RFC 7292 emphasizes avoiding weak ciphers in new implementations to mitigate cryptographic weaknesses.[24] These changes addressed vulnerabilities in older PKCS #12 files, such as those vulnerable to low-entropy passwords, without altering the fundamental syntax.[23] In June 2024, the IETF published RFC 9879, which amends RFC 7292 and PKCS #5 (RFC 8018) to specify the use of Password-Based Message Authentication Code 1 (PBMAC1) in PKCS #12, enhancing compatibility and security for password-based protections.[25]Technical Structure
File Format Layout
The PKCS #12 file format is defined as a binary structure using Abstract Syntax Notation One (ASN.1) Basic Encoding Rules (BER), specifically as a top-level PFX construct that encapsulates personal identity information such as private keys and certificates.[26] At its core, the PFX is an ASN.1 SEQUENCE comprising three primary elements: a fixed version number, an AuthenticatedSafe for the protected content, and an optional MacData for integrity verification.[26] The version field is always set to 3 (INTEGER {v3(3)}), reflecting the syntax version 1.1 as standardized.[26] This SEQUENCE serves as the outermost wrapper, ensuring a standardized hierarchical organization for interoperability across systems.[26] The AuthenticatedSafe, which forms the payload container, is itself a SEQUENCE OF ContentInfo objects, each tagged with an object identifier (OID) to specify its content type.[26] Common OIDs include 1.2.840.113549.1.7.1 (pkcs-7 1) for unencrypted Data, allowing direct access to inner SafeContents; 1.2.840.113549.1.7.6 (pkcs-7 6) for password-encrypted EncryptedData; and others for signed or enveloped variants.[26] Each ContentInfo encapsulates a SafeContents SEQUENCE OF SafeBag elements, where SafeBags hold the actual cryptographic objects like keys or certificates, as defined in the standard's bag types.[26] The optional MacData, present only when using password-based integrity, is another SEQUENCE containing a Message Authentication Code (MAC) via DigestInfo, a salt (OCTET STRING), and iteration count (INTEGER, default 1).[26] In terms of sequential layout, a PKCS #12 file begins with the outer PFX SEQUENCE header, immediately followed by the AuthenticatedSafe's ContentInfo sequences (which may be encrypted or signed), and concludes with the MacData if included for overall file integrity.[26] This linear progression from header to protected bags ensures a logical flow: parsing starts at the version for validation, proceeds to decrypt or verify the AuthenticatedSafe as needed, and ends with MAC computation for the entire structure.[26] File sizes vary significantly due to factors like the inclusion of optional certificate chains within bags and potential compression in implementations, though the core layout remains fixed according to the ASN.1 schema in RFC 7292.[26] This design supports scalability while maintaining a consistent binary footprint for secure transport.[26]Encoding and Algorithms
PKCS#12 employs the Basic Encoding Rules (BER), a binary encoding form of Abstract Syntax Notation One (ASN.1), to serialize its data structures, promoting interoperability among diverse systems and implementations.[26] This encoding ensures a compact, unambiguous representation of the file's components, such as private keys and certificates, in a platform-independent format.[26] For bulk encryption of sensitive data within the structure, the default algorithm specified is Triple DES in Cipher Block Chaining mode (3DES-CBC), identified by the object identifier (OID) 1.2.840.113549.1.12.1.3.[26] Key derivation for encryption and integrity protection relies on Password-Based Encryption Scheme 2 (PBES2, OID 1.2.840.113549.1.5.13), which incorporates PBKDF2 (Password-Based Key Derivation Function 2, OID 1.2.840.113549.1.5.12); implementations are recommended to use iteration counts of at least 1024 to enhance resistance against brute-force attacks, though higher values like 2048 or more are advisable for modern security.[26][27] Supported hash functions include SHA-1 (considered legacy due to vulnerabilities) and stronger options such as SHA-256, SHA-384, and SHA-512, allowing flexibility in digest computations for various operations.[26] File integrity is typically ensured through a Message Authentication Code (MAC) generated with HMAC-SHA1, which verifies the authenticity and unaltered state of the encoded content.[26] All algorithm selections are explicitly defined using OIDs within the ASN.1 structures, enabling precise identification and negotiation in compliant systems.[26]Security Mechanisms
Password-Based Protection
PKCS #12 employs password-based protection to secure sensitive contents, such as private keys and other data bags, by deriving symmetric keys from a user-supplied password for encryption. This mechanism, known as Password-Based Encryption Scheme 2 (PBES2), uses the Password-Based Key Derivation Function 2 (PBKDF2) to generate the necessary encryption key and initialization vector (IV) in a manner resistant to brute-force attacks.[1][28] The process begins with the user providing a password, which is combined with a randomly generated salt and a specified number of iterations. These inputs feed into PBKDF2 to produce a derived key of the required length. The salt, ideally as long as the output of the underlying hash function and consisting of random bits, ensures uniqueness across different encryptions, while the iteration count—recommended to be 1024 or more—slows down the derivation to thwart exhaustive search attacks. The resulting key and IV are then used with a symmetric encryption algorithm, such as AES, to protect the private keys and sensitive bags within the file.[22][29] Earlier versions of PKCS #12 supported the weaker Password-Based Encryption Scheme 1 (PBES1), which relied on a single iteration of a hash function like SHA-1 combined with algorithms such as RC4 or Triple DES, making it vulnerable to dictionary and brute-force attacks. However, RFC 7292 deprecates PBES1 for password privacy modes and mandates PBES2 with PBKDF2 for all new files to enhance security against such threats.[24][22] The PBKDF2 function operates as follows: the derived key is computed using the formula DerivedKey = PBKDF2(Password, Salt, Iterations, KeyLength, PRF), where PRF is a pseudorandom function such as HMAC-SHA1 or a stronger alternative like HMAC-SHA256. More precisely, PBKDF2 generates the output in blocks: for inputs Password (P), Salt (S), iteration count (c), and desired key length (dkLen), it computes T_i = F(P, S, c, i) for i = 1 to l, where F is the function that applies PRF(P, S || INT(i)) iteratively c times with XOR combinations, and l = ceil(dkLen / hLen) with hLen being the PRF output length. The final DerivedKey is the concatenation of these T_i blocks, truncated or padded as needed to match KeyLength. This structured derivation ensures that even weak passwords yield keys that are computationally expensive to crack offline.[29]Integrity and Encryption Methods
PKCS #12 provides integrity protection through an optional MacData structure, which employs a Message Authentication Code (MAC) to detect tampering with the file contents. The MacData includes a DigestInfo containing the MAC value, a salt (macSalt) for key derivation, and an iteration count (defaulting to 1, though higher values are recommended for security). This mechanism uses HMAC computed over the BER-encoded contents of the AuthenticatedSafe field, which encapsulates the protected objects such as private keys and certificates. Supported hash functions for the HMAC include SHA-1, SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224, and SHA-512/256, with the MAC key derived from a user-provided password combined with the salt and iteration count.[13] To address vulnerabilities in the legacy MAC derivation—particularly when using low iteration counts—RFC 9879 (published March 2024) updates PKCS #12 to support PBMAC1 (Password-Based Message Authentication Code 1) from RFC 8018. PBMAC1 combines PBKDF2 for key derivation with a MAC algorithm (e.g., HMAC-SHA-256), ensuring stronger protection against offline attacks. This update mandates higher iteration counts and approved hashes like SHA-256 or stronger, and is required for compliance with FIPS 140-3 as of 2024. Implementations should prefer PBMAC1 for new files to verify integrity robustly.[6][5] The MAC ensures end-to-end integrity verification upon import, allowing recipients to confirm the file has not been altered without requiring re-encryption of the inner contents. Specifically, the HMAC is generated using the derived MAC key on the entire AuthenticatedSafe, providing a tamper-evident seal that operates independently of the inner encryption layers. While the password plays a role in deriving the MAC key, the focus here is on the verification process itself, which confirms the authenticity of the protected data bundle. This optional integrity check is particularly valuable in scenarios where files are exchanged over untrusted channels, as it mitigates risks from undetected modifications.[30] For bulk encryption, PKCS #12 utilizes symmetric ciphers within the CMS EnvelopedData structure to protect the AuthenticatedSafe contents in password privacy mode. Legacy implementations commonly employ 3-Key Triple DES in CBC mode (identified by the OID pbeWithSHAAnd3-KeyTripleDES-CBC) or 2-Key Triple DES in CBC mode (pbeWithSHAAnd2-KeyTripleDES-CBC) for compatibility with older systems. These ciphers wrap the sensitive data, ensuring confidentiality against unauthorized access. However, due to vulnerabilities in weaker algorithms like 2-Key 3DES, modern implementations following RFC 7292 prioritize stronger options such as AES (e.g., AES-128-CBC or AES-256-CBC) through the PBES2 scheme defined in PKCS #5 v2.1, which supports a broader range of secure symmetric algorithms.[31][32] The use of CBC mode in these encryption schemes maintains backward compatibility while allowing for authenticated encryption modes in updated profiles, though the RFC deprecates the original Appendix B password privacy method in favor of PBKDF2-based key derivation paired with robust ciphers like AES to enhance resistance to brute-force and side-channel attacks. This layered approach—combining integrity via MacData with bulk encryption—enables secure storage and transfer of cryptographic material without exposing private keys during handling.[33]Usage and Applications
Common Scenarios
PKCS #12 files are frequently utilized for exporting SSL/TLS server certificates bundled with their corresponding private keys from certificate authorities, enabling secure deployment on web servers and applications. Commercial providers such as SSL.com and GlobalSign commonly deliver Domain Validated (DV) and Organization Validated (OV) certificates in this format to simplify installation across platforms like Windows and macOS.[34][8] Users of automated services like Let's Encrypt typically convert the issued PEM-format certificates and keys to PKCS #12 using OpenSSL for broader compatibility in server configurations.[35] In enterprise environments, PKCS #12 files serve as a standard mechanism for backing up and transferring user credentials, such as client certificates and private keys, between devices or across systems. This approach is particularly valuable for disaster recovery in public key infrastructure (PKI) setups, where administrators export these elements to a single encrypted file for safe archival or migration to new hardware.[36][37] Oracle documentation highlights how such exports protect access to the file via password-based encryption during transit.[37] PKCS #12 files are widely adopted for configuring email clients with S/MIME capabilities, where users import the file containing their personal certificate and private key to digitally sign and encrypt messages. This setup is supported in applications like Microsoft Outlook and Apple Mail, ensuring end-to-end security for email communications.[38] In VPN deployments, these files authenticate client endpoints by supplying the necessary credentials for mutual TLS handshakes, as seen in configurations for corporate access networks.[39] A practical interoperability scenario involves importing .p12 files into web browsers like Google Chrome for client certificate authentication in secure web sessions. This process allows users to present their identity during HTTPS connections that require two-way verification, such as in enterprise portals or API endpoints.[40][41]Implementation in Software
PKCS #12 files are widely supported through various open-source and platform-specific libraries, enabling developers to create, parse, and manage these files across different environments. OpenSSL, a prominent open-source toolkit, provides thepkcs12 command-line utility for generating and importing PKCS #12 files, offering cross-platform compatibility on Unix-like systems, Windows, and more.[7] Bouncy Castle, another open-source library, implements PKCS #12 functionality in Java and .NET, allowing for programmatic handling of keystore operations including key and certificate storage in a PKCS #12 format. PKCS #12 is also the standard keystore format in Java, used for exporting and importing private keys and certificate chains in Java applications and servers, such as in JSSE configurations.[42][43][44]
On Windows, Microsoft's Cryptography API (CAPI) and its successor, Cryptography API: Next Generation (CNG), facilitate the import and export of .pfx files, which are synonymous with PKCS #12, through functions like PFXImportCertStore for loading certificates and private keys into a certificate store.[45] For macOS and iOS, Apple's Security.framework supports PKCS #12 operations, including import and export via APIs such as SecKeychainItemExport with the kSecFormatPKCS12 option, ensuring seamless integration with the system's keychain services.[46]
A common example using OpenSSL to export a PKCS #12 file involves combining a private key and certificate: openssl pkcs12 -export -out file.p12 -inkey key.pem -in cert.pem. This command supports additional options like -iter <number> to specify the iteration count for password-based encryption, enhancing security against brute-force attacks; for instance, -iter 10000 sets 10,000 iterations for the key derivation.[7]
For programmatic access in Python, the cryptography library provides the pkcs12 module, which includes functions like serialize_key_and_certificates for creating PKCS #12 files and load_key_and_certificates for reading them, promoting cross-platform development without relying on system-specific APIs.