OpenPGP smart card application Functional Specification of the OpenPGP application on ISO Smart Card Operating Systems Version 2 0 1 Author Achim Pietig © 2009 April 22 Author Achim Pietig Lippstädter Weg 14 32756 Detmold Germany Email openpgppietig com This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be pre pared, copied, published and distributed, in whole or in part, w.
Definition of Abbreviations
ECDSA Elliptic Curve Digital Signature Algorithm
RFU Reserved for Future Use
UTF-8 UCS Transformation Format 8 (compatible with 7-bit US-ASCII for all characters < 80)
The OpenPGP application is compatible with multiple ISO-standard card operating systems and can be developed on various chips from different manufacturers All implementations must adhere to specific requirements to ensure functionality and compatibility.
• The OpenPGP application does evaluate Historical bytes for ‘Card capabilities’ For that reason the card shall provide a 'DO Historical bytes'.
• As single transmission protocol any ISO protocol is allowed.
• T=1 is preferred for cards with contacts (chaining support, extended length).
• The card may support different transmission protocols.
• High speed modes are requested (maximum as possible for the chip).
• Extended length (Lc and Le) fields are recommended.
• The card shall announce this feature in ‘Card capabilities’.
• If Extended length is not supported, the card shall support command chaining and/or GET RESPONSE for large command/response data.
• A common driver (CCID, PC/SC or CT-API) shall be supported.
• The driver should be available for several platforms (e.g Win32, Linux, Macin tosh)
• T=1 and T=0 shall be supported for cards with contacts
• High-Speed protocols should be supported.
• Extended length shall be supported.
Limitations in This Version
The current version of the OpenPGP application faces limitations in both the terminal application and the card functionality, primarily due to the lack of support for all requirements by existing cards and card readers.
• ECDSA and DSA are not supported (only RSA algorithm is used for all functions)
• High-Speed protocol may not be supported (terminal assumes standard values of ISO in that case)
RSA, with a minimum key size of 1024 bits, is currently the only defined algorithm for signature cards However, EN 14890 recommends ECDSA as the preferred algorithm for future use RSA should serve as a fallback option, as most smart cards will soon support ECDSA It is strongly advised to incorporate ECDSA into the OpenPGP specification (RFC 4880).
• High-Speed protocol may not be supported (terminal assumes standard values of ISO in that case).
The diagram illustrates the directory and data objects pertinent to the OpenPGP application, highlighting the storage of security-related data, such as keys and passwords, based on the operating system in use, whether in files, data objects, or alternative formats.
Private Keys Sig, Dec, Aut
Fingerprints Sig, Dec, Aut Application DOs Application DOs
Optional DF/EF Mandatory DO Optional DO
4 Directory and Data Objects of the OpenPGP Application
The DF_OpenPGP directory and its data objects form the core of the OpenPGP application Additionally, various applications may reside in specific Dedicated Files (DF) on the card Since the application is designed to support cards that lack a Master File (MF), it does not address any data outside the OpenPGP application.
Data Files and Objects in the MF or Other DFs
EF_DIR
The optional file identified as '2F00' under the MF may include one or more application templates and/or application identifiers as specified in ISO/IEC 7816-4 While the OpenPGP application does not request or evaluate this data file, it can serve to declare the application to third parties Therefore, relevant entries should be included if applicable.
• Application Identifier (tag ‘4F’), only the significant values should be used (6 bytes D27600012401)
• Application label (tag ‘50’), the application label should contain the following UTF-8 encoded text: OpenPGP
An entry in the EF_DIR typically serves as an application template (Tag 61), which can either be stored within a record or added to a preceding template in the case of a binary structure Each entry comprises specific content relevant to its function.
DF_OpenPGP
The OpenPGP application's directory is flexible in its storage location on the card, lacking a fixed File Identifier (FID) for easy integration into various contexts The FID can be designated by the card manufacturer or other entities if necessary All data objects associated with the application are accessible within this directory Users can select the OpenPGP application using the SELECT FILE command immediately after resetting the card, although the application on the terminal does not evaluate any returned File Control Parameters (FCPs).
The OpenPGP application is identified by a unique application identifier (AID) that is 16 bytes long Each card has its own distinct AID, which is advisable to incorporate into certificates for client/server authentication The Registration Identifier (RID) within the AID is officially registered by FSF Europe e.V.
Coding D2 76 00 01 24 01 xx xx xx xx xx xx xx xx 00 00
Name RID of FSFE Application Version Manufacturer Serial num ber
RID Registered application provider identifier (unique identification of
FSFE), ISO 7816-5 PIX Proprietary application identifier extension
(defined for OpenPGP application) Application Indication of the application (OpenPGP)
Version Version number of the application
Manufacturer Unique code for the manufacturer of the application (card)
Serial number Unique serial number
RFU Reserved for Future Use
This 1-byte binary value identifies the application, enabling the future development of various applications under the oversight of FSF Europe e.V The defined values are as follows:
The version number, represented in 2 bytes using Binary-Coded Decimal (BCD), provides crucial information regarding the current status of the application and enables the announcement of updates to external parties.
Main version Secondary version (values from 00 – 99)
To successfully identify a card in open networks, such as key servers, and facilitate log-in processes on local or open networks, unique application numbers associated with specific cards are essential Each card manufacturer or personalizer is assigned a unique address, regulated by FSF Europe e.V., which is provided free of charge to registered manufacturers This ensures that only authorized entities can create applications compatible with OpenPGP standards, akin to how MAC addresses function for network cards Additionally, the system utilizes 2-byte binary coding, reserving the values 0000 and FFFF for testing purposes.
Each OpenPGP application card from a manufacturer or personalizer features a unique 4-byte serial number, formatted from Most Significant Bit (MSB) to Least Significant Bit (LSB) The manufacturer is responsible for ensuring that no duplicate serial numbers exist, similar to MAC addresses in networks The numbering typically begins with 00 00 00 01 for the first card, with subsequent numbers incremented automatically, although gaps in the sequence are permissible.
User Verification in the OpenPGP Application
Resetting Code
Users receive a personalized card issued by an authority or company, complete with keys and a password While users can operate the card, they cannot modify essential data such as keys and data objects (DOs) controlled by the issuer Users must know their user-password (PW1) but do not have access to the admin-password (PW3) In cases where PW1 is blocked, a Resetting Code (RC) is provided by the issuer, which has the same format as the password and is stored in a data object (DO) labeled 'RC' The maximum length of the Resetting Code is specified in the PW Status bytes, with a minimum length of 8 bytes This code is used with the command RESET RETRY COUNTER as a substitute for PW3, exclusively for resetting PW1 Initially, DO 'RC' is empty, and the error counter starts at zero, making it unusable until activated The Resetting Code comes with an error counter set to 3, which can be checked using the GET DATA command.
DO 'RC' can be set to any value with a PUT DATA command after correct verification of the admin-password (PW3), the error counter then is set to 3.
Data Objects (DO)
DOs for GET DATA
The GET DATA command supports various Data Objects (DOs) that can be accessed in the OpenPGP DF of the card Simple DOs (S) provide only the value, while constructed DOs (C) include their tag and length Additional DOs may be present in constructed DOs, but they are not evaluated by the OpenPGP application in the terminal Certain DOs, indicated in cursive, cannot be accessed directly as single DOs; instead, the terminal application utilizes the non-cursive DOs, primarily constructed ones Some DOs are optional, as noted in the Extended capabilities, and may appear multiple times in the table if defined as both single and constructed DOs The order of DOs within a constructed DO may vary.
0101 S Optional DO for private use, max 254 (dec.) bytes (binary, propriet ary), can be used to store any information.
0102 S Optional DO for private use, max 254 (dec.) bytes (binary, propriet ary), can be used to store any information.
0103 S Optional DO for private use, max 254 (dec.) bytes (binary, propriet ary), can be used to store any information.
0104 S Optional DO for private use, max 254 (dec.) bytes (binary, propriet ary), can be used to store any information.
4F S Application identifier (AID), 16 (dec.) bytes (ISO 7816-4)
5E S Login data, max 254 (dec.) bytes (binary, proprietary)
This DO can be used to store any information used for the Log-In process in a client/server authentication (e.g user name of a net work).
5F50 S Uniform resource locator (URL, as defined in RFC 1738), up to 254
(dec.) bytes The URL should contain a Link to a set of public keys in OpenPGP format, related to the card.
5F52 S Historical bytes, up to 15 bytes (dec.), according to ISO 7816-4
Card capabilities shall be included.
5B S Name (up to 39 bytes (dec.), according to ISO/IEC 7501-1)
5F2D S Language preferences, max 8 bytes (according to ISO 639)
5F35 S Sex, 1 byte (according to ISO 5218)
4F S Application identifier (AID), 16 (dec.) bytes (ISO 7816-4)
5F52 S Historical bytes, up to 15 bytes (dec.), according to ISO 7816-4
Card capabilities shall be included.
1 Byte Algorithm ID, according to RFC 4880 further bytes depending on algorithm (e.g length modulus and length exponent)
C4 S PW Status Bytes (7 bytes, binary)
1 st byte: 00 = PW1 (no 81) only valid for one PSO:CDS command
01 = PW1 valid for several PSO:CDS commands
2 nd byte: max length of PW1 (user)
3 rd byte: max length of Resetting Code (RC) for PW1
4 th byte: max length of PW3 (admin) Byte 5, 6, 7 (first byte for PW1, second byte for Resetting Code, third byte for PW3):
Error counter of PW1, RC and PW3 If 00 then the corres ponding PW/RC is blocked Incorrect usage decrements the counter, correct verification sets to default value = 03
C5 S Fingerprints (60 bytes (dec.), binary, 20 bytes (dec.) each for Sig,
The article discusses the representation of private keys and CA fingerprints, where zero bytes signify an undefined private key It also mentions a list of CA fingerprints, consisting of 60 bytes in decimal format and binary data of 20 bytes each, which are associated with "Ultimately Trusted Keys." These fingerprints can be utilized to verify public keys from servers.
The CD S includes a list of generation dates and times for public key pairs, represented in a 12-byte decimal binary format Each value consists of 4 bytes in Big Endian format for Signature (Sig), Decryption (Dec), and Authentication (Aut), with all values indicating seconds since January 1, 1970 The default value for these timestamps is set to 00000000, indicating that it is not specified.
93 S Digital signature counter (counts usage of Compute Digital Signa ture command), 3 bytes binary, ISO 7816-4
This Data Object (DO) is intended for storing a certificate, such as an X.509 certificate, associated with the AUT-key on the card It plays a crucial role in client-server authentication scenarios that require specific non-OpenPGP certificates The maximum length of this DO is specified in the Extended capabilities section, and while the content should follow a TLV (Tag-Length-Value) structure, further details on this aspect are beyond the scope of this specification.
It may be necessary to use GET RESPONSE to read the content with GET DATA.
C4 S PW Status Bytes (7 bytes, binary)
1 st byte: 00 = PW1 (no 81) only valid for one PSO:CDS command
01 = PW1 valid for several PSO:CDS commands
2 nd byte: max length of PW1 (user)
3 rd byte: max length of Resetting Code (RC) for PW1
4 th byte: max length of PW3 (admin) Byte 5, 6, 7 (first byte for PW1, second byte for Resetting Code, third byte for PW3):
Error counter of PW1, RC and PW3 If 00, then the corres ponding PW/RC is blocked Incorrect usage decrements the counter, correct verification sets to default value = 03.
DOs for PUT DATA
The following DOs are supported by the PUT DATA command They can be accessed at least in the OpenPGP DF of the card.
0101 S Optional DO for private use, max 254 (dec.) bytes (binary)
0102 S Optional DO for private use, max 254 (dec.) bytes (binary)
0103 S Optional DO for private use, max 254 (dec.) bytes (binary)
0104 S Optional DO for private use, max 254 (dec.) bytes (binary)
4D C Extended Header list (used for key import), uses:
7F48 (Cardholder private key template) 5F48 (Cardholder private key)
This Data Object (DO) is intended to securely store a certificate, such as an X.509, for the AUT-key on the card It plays a crucial role in client-server authentication, particularly when specific non-OpenPGP certificates are required The maximum length of this DO is specified in the Extended capabilities, and while the content must be TLV-constructed, detailed specifications are beyond the scope of this document.
It may be necessary to use command chaining for writing the DO with PUT DATA.
C1 S Optional DO (announced in Extended capabilities).
Algorithm attributes signature C2 S Optional DO (announced in Extended capabilities).
Algorithm attributes decryption C3 S Optional DO (announced in Extended capabilities).
Algorithm attributes authentication C4 S Optional DO (announced in Extended capabilities).
1 st PW Status Byte (1 byte binary):
00 = PW1 (No 81) only valid for one PSO:CDS command
01 = PW1 valid for several PSO:CDS commands C7 S Fingerprint (binary, 20 bytes dec.) for signature key, format accord ing to RFC 4880 C8 S Fingerprint (binary, 20 bytes dec.) for decryption key
C9 S Fingerprint (binary, 20 bytes dec.) for authentication key
CA S 1 st CA-Fingerprint in list (binary, 20 bytes dec.)
CB S 2 nd CA-Fingerprint in list (binary, 20 bytes dec.)
CC S 3 rd CA-Fingerprint in list (binary, 20 bytes dec.)
CE S Generation date/time of signature key (4 bytes Big Endian, format according to RFC 4880
CF S Generation date/time of decryption key (4 bytes Big Endian)
D0 S Generation date/time of authentication key (4 bytes Big Endian)
D1 S Optional DO (announced in Extended capabilities) for SM.
SM-Key-ENC for cryptogram (24 bytes dec in case of Triple-DES,
16 bytes in case of AES) D2 S Optional DO (announced in Extended capabilities) for SM.
SM-Key-MAC for cryptographic checksum (24 bytes dec in case of Triple-DES, 16 bytes in case of AES)
D3 S Resetting Code, 0 or 8 – xx bytes (dec.), binary
F4 C Optional DO (announced in Extended capabilities) for SM.
Container for both SM keys (ENC and MAC) with Tags D1 and D2.Useful for updating or deleting both keys simultaneous.
DOs in Detail
The following chapter describes some DOs in detail, especially the proprietary DOs.
Optional Data Objects (DOs) can be utilized by cardholders, administrators, or applications for accessing proprietary data, such as password lists The key distinction among these DOs lies in their access conditions, which are specified in the Extended Capabilities.
The interindustry data element comprises up to 39 bytes, utilizing characters from the ISO 8859-1 (Latin 1) alphabet, which aligns with 7-bit US-ASCII for characters less than 80 This data element includes both the surname (family name) and forename(s), along with any name suffixes such as "Jr." or numeric designations Each component is delineated by a single '