Functional Specification of the OpenPGP application on ISO Smart Card Operating Systems. Version Author: Achim Pietig

Transcription

1 Functional pecification of the on IO mart Card Operating ystems Author: Achim Pietig June 30

2 Author: Achim Pietig Lippstädter Weg Detmold Germany 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 prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references. Many thanks to all people for advice, error correction and hints to this specification. Achim Pietig, Detmold The author does not assume responsibility nor give a guarantee for the correctness and/or completeness of the features and functions described in this document. The author is unable to accept any legal responsibility or liability for incorrect and/or incomplete details and their consequences. Furthermore, the author reserves the right to revise these specifications for technical reasons and make amendments and/or updates to the same.

3 History V1.0 to V1.1: Change of access rights for command GENERATE AYMMETRIC KEY PAIR and P1=81 (reading of public key) to always. Adjustment of the literature. New Data Objects for private use, with different access conditions. This optional feature is announced in Extended capabilities. New Data Objects for key generation date/time. Data Object 'PW tatus Bytes' (C4) mandatory for GET DATA as single object. V1.1 to V2.0: Correction of AID description (RID of FFE). Adjustment of the literature. Alignment with changes and innovations in IO 7816 and EN Change in VERIFY command and password management. Enhancement of Extended capabilities. Enhancement of Algorithm attributes. Reset functionality (life cycle management). Definition of key import according to IO Additional Hash algorithms and different behaviour of PO:CD command. Improvements for cards without MF. New Data Objects: Cardholder certificate (IO 78166) Extended header list for key import, supporting Cardholder private key template (IO 78166/8) Cardholder private key (IO 78166/8) Historical bytes (IO 78164/6) Algorithm attributes for PUT DATA Resetting Code for PUT DATA M keys for PUT DATA Deletion of DOs 'FF', 'E0''E2'. upport for ecure Messaging. upport for Command Chaining. upport for different algorithm and key length (see PUT DATA for Algorithm attributes). Introduction of a Resetting Code for REET RETRY COUNTER. implification in password management. everal editorial clarifications. V2.01 to 2.1: upport for AE algorithm for PO:DEC. New Data Objects: AEKey for PO:DEC Change access conditions for TERMINATE. Update list of tatus Bytes IN for TERMINATE and ACTIVATE corrected

4 V2.1 to V3.0: Adjustment of the literature. Alignment with changes and innovations from IO 78164, 8 and EN (former 14890). Introducing Extended length information (DO 7F66). Introducing General feature management (DO 7F74). Add new commands GET NEXT DATA and ELECT DATA from IO Improved description of ecure Messaging. Extend maximum length of several DOs with variable length and announce max. length in Extended Capabilities. New Data Objects: Cardholder certificate (IO 78166) for Decipher and ign. Extended length information (DO 7F66). UIFDOs (D6 D8) everal corrections and editorial improvements. Obsolet definitions from old versions are deleted. 3DE is discarded for ecure Messaging. RA 1024 is removed. HA1 and RIPEMD160 are removed. Modified and additional flow charts. Enhancement of VERIFY (additional PIN format) upport for ECDA/DH algorithm: Enhancement of GENERATE PUBLIC KEY PAIR Enhancement of key import Enhancement of PO:CD, DEC and INTAUT Enhancement of Algorithm attributes Modification of Extended Capabilities. Introducing User Interaction Flag V3.0 to V3.0.1: ome error corrections. Enhancement of User Interaction Flag for DOs D6 to D8

5 TABLE OF CONTENT 1 Introduction Definition of Abbreviations General Requirements Data tructure Directory and Data Objects of the OpenPGP Application Files and Objects under the MF EF.DIR Historical bytes EF.ATR/INFO Extended length information General feature management DF.OpenPGP Application Identifier (AID) User Verification in the OpenPGP Application Resetting Code Data Objects (DO) DOs for GET DATA DOs for PUT DATA DOs in Detail Private Use Name Language Preferences ex User Interaction Flag Extended Capabilities Algorithm Attributes upported algorithms Private Key Template Length Field of DOs ecurity Architecture Historical Bytes Card Capabilities (73) Card service data (31) Commands Usage of IO tandard Commands Commands in Detail ELECT VERIFY CHANGE REFERENCE DATA REET RETRY COUNTER ELECT DATA GET DATA GET NEXT DATA PUT DATA GET REPONE

6 PO: COMPUTE DIGITAL IGNATURE Hash Algorithms DigestInfo for RA PO: DECIPHER INTERNAL AUTHENTICATE Client/erver Authentication GENERATE AYMMETRIC KEY PAIR GET CHALLENGE TERMINATE DF ACTIVATE FILE Command Usage under Different I/O Protocols Class Byte Definitions ecure Messaging (M) Logical Channels Command Chaining Life Cycle Management tatus Bytes Literature Flow Charts Application election reading main DOs Reading optional Data objects Compute Digital ignature Decrypt Message Generate Private Key Client/erver Authentication torage of Card Holder Certificates Domain parameter of supported elliptic curves

7 1 Introduction This functional specification describes the based on the functionality of an IO smart card operating system. In principle it defines the interface of the application between card and terminal, in this context the OpenPGP software with a standard card reader on PC/C and/ or CCID basis. The solution takes care of use of international standards, avoiding of patents, free usage under GNU General Public License, independence from specific smart card operating systems (second source), easy enhancement for future functionality, international use. Consequently this specification does not deal with the description of the global commands and data fields of the card, the security functions generally provided by the card, any features that apply to more than one application, such as transmission protocols, nor with the description of the general mechanical and electrical characteristics of the card. In particular, the specification provides a detailed description of the data objects directly related to the applications and their respective content formats. Contents of the application data are only prescribed if they represent a constant factor of the application. Besides the definitions in this specification a card may support any other protocols, commands, data and variants. However, the (e. g. GnuPG) should use only the defined features in this specification to be compatible to different implementations. The encoding values mentioned in the specification are stated in hexadecimal form, unless otherwise indicated. 7

8 1.1 Definition of Abbreviations AC AE AID APDU ATR AUT BCD CLA CP CRT DEC dec. DF DIR DO DI ECDH ECDA EF FCI FCP FID IN LC MF O PK PW RC RFU RA E IG K M UID UIF URL UTF8 VR Access Condition Advanced Encryption tandard Application Identifier Application Data Unit Answer To Reset AUThentication Binary Coded Decimal CLAss byte Control Parameter Control Reference Template DECipher Decimal Dedicated File DIRectory Data Object Digital ignature Input Elliptic Curve Diffie Hellman Elliptic Curve Digital ignature Algorithm Elementary File File Control Information File Control Parameter File IDentifier INtruction byte Life Cycle tatus Master File Operating ystem Public Key PassWord Resetting Code Reserved for Future Use RivesthamirAdleman ecurity Environment IGnature ecret Key ecure Messaging Unique card IDentifier User Interaction Flag Uniform Resource Locator UC Transformation Format 8 (compatible with 7bit UACII for all characters < 80) Virtual Root data object 8

9 2 General Requirements The is designed to run under several IOcompatible card operating systems. The application can be developed on various chips and by different manufacturers. For all implementations, the following requirements should be fulfilled. Card > The does evaluate Historical bytes for Card capabilities. For that reason the card shall provide a 'DO Historical bytes' at application level. The may evaluate Extended length information. For that reason the card should provide the content as DO at application level. As single transmission protocol any IO protocol is allowed. T=1 is preferred for cards with contacts (extended length, chaining for APDUs > 2048 bytes). 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 (at least 2048 bytes for a single APDU under T=1) The card shall announce this feature in Card capabilities. If Extended length is not supported (T=0), the card should support command chaining and/or ENVELOPE/GET REPONE for large command/response data. Contactless cards should support random UID (Unique card Identifier) to avoid collecting user profiles (Datenschutz). Reader (informative) > A common driver (CCID, PC/C or CTAPI) shall be supported. The driver should be available for several platforms (e. g. Win32/64, Linux, Macintosh). T=1 shall be supported for cards with contacts (T=0 optional). Highpeed protocols should be supported. Extended length should be supported with a minimum of 2048 bytes for APDUs for in and ouput. Under T=0 ENVELOPE and GET REPONE are required to transport long APDUs. Command chaining should be supported. 9

10 3 Data tructure The following diagram gives an overview over files and data objects (DO) relevant for the. ecurity related data (e. g. keys, passwords) are stored in accordance with the used O (files, data objects or other). 10

11 4 Directory and Data Objects of the OpenPGP Application The DF.OpenPGP directory and the data objects contained therein constitute the. On the card several other applications may exist in specific Dedicated Files (DF). 4.1 Files and Objects under the MF The uses its own set of data, including keys and passwords. No files/data of the MF or other DFs are needed for the application. However the operating system may store common data, like passwords, shareable in the card and use them for several applications EF.DIR This optional file under the MF (file identifier: 2F ) may contain one or several application templates and/or application identifiers as defined in IO/IEC The data file is not requested and evaluated by the, but may be used to declare the application to 3rd parties. The following entries should be added in that case: Application Identifier (tag 4F ), only the significant values should be used (6 bytes = 'D ') Application label (tag 50 ), the application label should contain the following UTF8 encoded text: OpenPGP Example: An entry in EF.DIR is an application template (Tag 61) in most cases. The template is stored in a record or is appended to a previous template in case of a binary structure of the EF.DIR. An entry has the content: F 06 D 'OpenPGP' If the card indicates DO handling for EF.DIR, then it should support the GET DATA command for reading all DOs in the EF at once ('CB 2F 02 5C ') directly after a reset. 11

12 4.1.2 Historical bytes In the Answer To Reset (ATR) of a card with contacts Historical bytes may be present. These bytes are available as DO ('5F52') for all types of smart cards on application level also and are relevant only for the selected application in that case. In the OpenPGP card application the DO Historical bytes is available directly after ELECT as single DO or in between the Application Related Data ('6E') EF.ATR/INFO The optional file EF.ATR/INFO under the MF (file identifier: 2F01 ) contains Extended length information for APDUs, if extended length is announced in the Historical bytes. If the card supports additional hardware like buttons or fingerprint sensors for special user interaction EF.ATR/INFO should contain the General feature management DO ('7F74') also. If no additional hardware is present this DO can be omitted. If the card indicates DO handling for EF.ATR/INFO, then it should support the GET DATA command for reading all DOs in the EF at once ('CB 2F C ') directly after a reset Extended length information In the OpenPGP card application the DO Extended length information ('7F66') shall be available directly after ELECT as single DO and in between the Application Related Data ('6E'). The DO contains the following data objects. 7F66 08 Extended length information Maximum number of bytes in a command APDU Unsigned Integer, 2 bytes (Most ignificant Bit... Least ignificant Bit) Maximum number of bytes in a response APDU Unsigned Integer, 2 bytes The maximum length of an APDU field means the total amount of bytes sent to or received from the card (including M) in any command. If commands exceed the announced maximum length by definition, the card shall support chaining. If a response exceeds the maximum length (e. g. GET DATA), the card answers with status bytes 61xx and the remaining data can be read with GET REPONE. 12

13 If Extended Length is not supported by a card or if the Extended Length information is not present, then a maximum length of 256 (dec.) bytes is assumed (short length). The card should support chaining for command and response if any defined commands have this requirement General feature management In the OpenPGP card application the optional DO General feature management ('7F74') may be available directly after ELECT as single DO and in between the Application Related Data ('6E'). The DO announced additional hardware for user interaction, if present the User Interaction Flag (UIF) in the related DOs shall be evaluated. The DO contains a data object with Tag '81' with the following content: b8 1 b7 1 b6 b5 b4 b3 b b1 Meaning Display (defined by IO/IEC 78164) Biometric input sensor (defined by IO/IEC 78164) Button/Keypad LED Loudspeaker Microphone Touchscreen 1 Battery Actual only the behaviour for Button/Keypad is defined, e. g. '7F ' announce a button or keypad. 4.2 DF.OpenPGP The directory of the is stored anywhere in the card. It has no fixed File Identifier (FID), so it is easy to integrate the application in any existing context. The FID (if needed) can be chosen by the card manufacturer or any other party. The directory contains all data objects of the application. The can be selected with a ELECT command directly after a Reset of a card. The ELECT command may return FCPs (File Control Parameter), but the in the terminal do not need to evaluate them. A valid ELECT of an application directory sets the curconstructeddo pointer to the Virtual Root DO and adds all data objects in the application to the current template. 13

14 4.2.1 Application Identifier (AID) The is selectable by a unique application identifier (see ELECT). The AID has a length of 16 bytes (dec.) and is coded in the following way. The AID is unique for each card and it is recommended to integrate this value in certificates, e.g. for client/server authentication. The RID in the AID is registered by FF Europe e. V. RID PIX Coding D xx xx xx xx xx xx xx xx Length (dec.) Name RID of FFE Application Version Manufacturer erial number RID PIX Application Version Manufacturer erial number RFU 2 RFU Registered application provider identifier (unique identification of FFE), IO Proprietary application identifier extension (defined for ) Indication of the application (OpenPGP) Version number of the application Unique code for the manufacturer of the application (card) Unique serial number Reserved for Future Use 14

15 Application This value (1 byte binary) specifies the application. With this definition it is possible to design different applications under control of FF Europe e. V. in the future. The following values are defined: FF Reserved (standard) martchess Reserved Version The version number (2 bytes, BCD) gives information about the current status of the application. With this value it is possible to announce updates to the outside world. The version number is defined as follows: Byte 1 Main version Byte 2 econdary version (values from 99) Example: A version is coded Manufacturer To identify a card in open networks (e. g. key servers) and for the purpose of LogIn in local or open networks or to a single computer, it is necessary to have unique application numbers (related to a specific card). For that reason, every card manufacturer or personaliser has a unique address. This manufacturer identification is controlled by FF Europe e. V. and given to every interested manufacturer for free. Only registered manufactures are allowed to produce applications compatible with an. The system works similar to MAC addresses on network cards. The 2 bytes are coded binary and the values '' and 'FFFF' are reserved for test purposes. 15

16 erial Number Each on a card from a manufacturer/personaliser has a unique serial number. The manufacturer/personaliser is responsible that no cards with duplicate numbers will occur in the outside world (like MAC addresses in networks). The number is 4 byte long (binary) and has the format MB.... LB (Most ignificant Bit... Least ignificant Bit). It should start with 01 for the first card with an of a manufacturer and normally is incremented automatically by him. However gaps in the range of numbers are allowed. 4.3 User Verification in the OpenPGP Application The uses two local passwords for user verification, called PW (PW1 with 6 characters/digits minimum and PW3 with 8 characters/digits minimum). PW1 is also called userpassword and PW3 adminpassword. PW1 (user) is the password used for signing and decryption operations, PW3 (admin) is the security officers password. PW1 is needed for everyday use of the card, while PW3 is used to manage the card. The format of the PWs is UTF8 (case sensitive) by default or PIN block format 2 (digits only, useful for class 2/3 readers with PIN pad) as option. The format and maximum length for each PW is declared in the 'PW status' DO and can be changed by the user by option (announced in Extended capabilities). The card checks length and format of the passwords. The storage of the PWs is dependent on the card O, global PWs (used by other applications as well) may be used but mapped to the application as local. PW1 is used as access condition for the command PO:CD, PO:DEC, INTAUT, GET DATA and PUT DATA. The uses PW3 as access condition for the commands REET RETRY COUNTER, PUT DATA, GENERATE AYMMETRIC KEY PAIR and TERMINATE DF. All PWs use an error counter with an initial value of 3. This error counter is readable with GET DATA. After correctly verifying the PW, the access status of the corresponding PW remains valid up to a REET of the card, a ELECT to a different DF or an internal resetting by specific commands. The command PO:CD uses PW1 in a different mode then the other commands, it is valid for one command only and has to be presented again for the next signature calculation, for that reason terminals and software should not cache the passwords of a card! This behaviour can be changed by the user by option, so that the password remains valid in the 16

17 card up to a reset or changing the application. The other passwords are valid for the complete session by default. If the card is delivered without personalisation and/or PW letter, then a default content is assumed (UTF8): PW1 = (6 bytes, ); PW3 = (8 bytes, ). It is highly recommended that the card holder change these values Resetting Code If, for example, the card is issued by an authority or company, the users will get a complete personalised card with keys and password. The user should be able to work with the card, but is not permitted to change card data like keys and DOs under control of the issuer. He shall know his userpassword (PW1), but is not aware of the adminpassword (PW3). To reset PW1 in the case of a blocked error counter, a special Resetting Code (RC) is introduced. The issuer should give the RC to the user together with his password. The Resetting Code has the same format as the password and is stored in a DO 'RC'. The maximum length is announced in PW status bytes, the minimum length is 8 letters or digits. The format is the same as for PW1, the admin can change the values (optional). The Resetting Code can be used within the command REET RETRY COUNTER instead of the adminpassword (PW3). It is only valid for resetting PW1. By default DO 'RC' is empty and the related error counter is zero, so it cannot be used. The Resetting Code has an error counter with an initial value of 3. This error counter is readable with GET DATA. The DO 'RC' can be set to any value with a PUT DATA command after correct verification of the adminpassword (PW3), the error counter then is set to 3. 17

18 4.4 Data Objects (DO) To keep the interface to terminals simple and for the reason to integrate the OpenPGP application in different card O, all relevant data elements for the application are stored as data objects. Terminals can run the application only with the ELECT (DATA), GET (NEXT) DATA, PUT DATA and cryptographic commands. Changing of any file identifier, short file identifier, file type or file structure has no influence on the terminal interface. DOs are stored in a TLV (Tag, Length, Value) format, whenever possible definitions of IO (e. g ) are used. This application structure is in compliance with the latest additions of IO 78164, where each DF may have a Virtual Root data object (Tag '7F70') and any DO under this root may have its own access conditions. The OpenPGP card application does not use the DO '7F70' directly. 18

19 4.4.1 DOs for GET DATA The following DOs shall be supported by the GET (NEXT) DATA command. They can be accessed at least in the OpenPGP DF of the card. imple DOs () return only the value with GET DATA. Constructed DOs (C, marked yellow) are returned including their tag and length. In constructed DOs additional DOs may occur (not defined here) but are not evaluated by the in the terminal. The DOs in cursive letters cannot accessed directly with GET DATA as single DO, the in the terminal uses the noncursive DOs (mostly constructed) only. ome of the DOs are optional (marked green), the occurrence is announced in Extended capabilities. DOs may appear several times in the table, if they are defined as single DO and occur in constructed DOs also. The order of DOs in a constructed DO may vary. Tag Format F 5E 5F50 5F52 7F66 C 7F B 5F2D 5F35 C C Length 0 max. Description Optional DO for private use (binary, proprietary), can be used to store any information. The maximum length of this DO is announced in Extended capabilities. 0 max. Optional DO for private use (binary, proprietary), can be used to store any information. The maximum length of this DO is announced in Extended capabilities. 0 max. Optional DO for private use (binary, proprietary), can be used to store any information. The maximum length of this DO is announced in Extended capabilities. 0 max. Optional DO for private use (binary, proprietary), can be used to store any information. The maximum length of this DO is announced in Extended capabilities (dec.) Full Application identifier (AID), IO max. Login data (binary, proprietary) This DO can be used to store any information used for the LogIn process in a client/server authentication (e.g. user name of a network). The maximum length of this DO is announced in Extended capabilities. 0 max. Uniform resource locator (URL, as defined in RFC 1738). The URL should contain a Link to a set of public keys in OpenPGP format, related to the card. The maximum length of this DO is announced in Extended capabilities (dec.) Historical bytes, Card service data and Card capabilities shall be included, mandatory for the. 08 Extended length information (IO 78164) with maximum number of bytes for command and response. 03 General feature management (optional) var. Cardholder Related Data 0 39 (dec.) Name according to IO/IEC 75011) 28 Language preferences (according to IO 639) 1 ex (according to IO 5218) 19

20 Tag Format 6E 4F 5F52 C 7F66 C 7F74 73 C0 C C C1 C2 C3 C4 C5 C6 CD Length Description var. Application Related Data 5 16 (dec.) Application identifier (AID), IO (dec.) Historical bytes, Card service data and Card capabilities shall be included, mandatory for the. 08 Extended length information (IO 78164) with maximum number of bytes for command and response. 03 General feature management (optional) var. Discretionary data objects 10 (dec.) Extended capabilities Flag list var. Algorithm attributes signature 1 Byte Algorithm ID, according to RFC 4880/6637 further bytes depending on algorithm (e. g. length modulus and length exponent). var. Algorithm attributes decryption var. Algorithm attributes authentication 7 PW status Bytes 1st byte: = PW1 (no. 81) only valid for one PO:CD command 01 = PW1 valid for several PO:CD commands 2nd byte: max. length and format of PW1 (user) Bit 17 = max. length, for PIN format 2 always '08' (real PIN length up to 12 digits) Bit 8 = 0 for UTF8 passwords 1 for PIN block format 2 3rd byte: max. length of Resetting Code (RC) for PW1 4th byte: max. length and format of PW3 (admin), see PW1 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 then the corresponding PW/RC is blocked. Incorrect usage decrements the counter, correct verification sets to default value = (dec.) Fingerprints (binary, 20 bytes (dec.) each for ig, Dec, Aut in that order), zero bytes indicate a not defined private key. 60 (dec.) List of CAFingerprints (binary, 20 bytes (dec.) each) of Ultimately Trusted Keys. Zero bytes indicate a free entry. May be used to verify Public Keys from servers. 12 (dec.) List of generation dates/times of public key pairs, binary. 4 bytes, Big Endian each for ig, Dec and Aut. Each value shall be seconds since Jan 1, Default value is (not specified). 20

21 Tag D6 Format Length 02 D7 02 D8 02 7A 93 C 5 3 7F 21 C 0 max. C4 7 Description User Interaction Flag (UIF) for PO:CD (optional): If not supported, DO is not available. First byte = : UIF disabled (default) 01: UIF enabled 02: UIF permanently enabled (not changeable with PUT DATA, optional) econd byte = Content from General feature management ('20' for button/keypad) UIF for PO:DEC (optional): ee UIF for PO:CD UIF for PO:AUT (optional): ee UIF for PO:CD ecurity support template Digital signature counter (counts usage of Compute Digital ignature command), binary, IO Cardholder certificate (each for AUT, DEC and IG) These DOs are designed to store a certificate (e. g. X.509) for the keys in the card. They can be used to identify the card in a clientserver authentication, where specific nonopenpgpcertificates are needed, for MIME and other x.509 related functions. The maximum length of the DOs is announced in Extended capabilities. The content should be TLVconstructed, but is out of scope of this specification. The DOs are stored in the order AUT (1st occurrence), DEC (2nd occurrence) and IG (3rd occurrence). toring the AUT certificate at first occurrence is for downward compatibility with older versions of this specification. PW tatus Bytes (binary) 1st byte: = PW1 (no. 81) only valid for one PO:CD command 01 = PW1 valid for several PO:CD commands 2nd byte: max. length and format of PW1 (user) Bit 17 = max. length, for PIN format 2 always '08' (real PIN length up to 12 digits) Bit 8 = 0 for UTF8 passwords 1 for PIN block format 2 3rd byte: max. length of Resetting Code (RC) for PW1 4th byte: max. length and format of PW3 (admin), see PW1 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, then the corresponding PW/RC is blocked. Incorrect usage decrements the counter, correct verification sets to default value =

22 4.4.2 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. The content of possibly empty DOs can be deleted with PUT DATA and empty Lc (no data). Tag D Format C 5B 5E 5F2D 5F35 5F50 7F 21 C C1 C2 C3 C4 C7 C8 Length 0 max. 0 max. 0 max. 0 max. var. Description Optional DO for private use (binary) Optional DO for private use (binary) Optional DO for private use (binary) Optional DO for private use (binary) Extended Header list (used for optional key import), uses: 7F48 (Cardholder private key template) 5F48 (Cardholder private key) 0 39 (dec.) Name 0 max. Login data 28 Language preferences 1 ex 0 max. Uniform resource locator (URL) 0 max. Cardholder certificate (AUT, DEC, IG) These DOs are designed to store a certificate (e.g. X.509) for the AUT, DEC and IGkey in the card. The maximum length of the DOs is announced in Extended capabilities. The content should be TLVconstructed, but is out of scope of this specification. The DOs are stored in the order AUT (1st occurrence), DEC (2nd occurrence) and IG (3rd occurrence). var. Optional DO (announced in Extended capabilities). Algorithm attributes signature var. Optional DO (announced in Extended capabilities). Algorithm attributes decryption var. Optional DO (announced in Extended capabilities). Algorithm attributes authentication 1 Optional DO (announced in Extended capabilities). 1st PW tatus Byte (1 byte binary): = PW1 (No. 81) only valid for one PO:CD command 01 = PW1 valid for several PO:CD commands 2nd byte: max. length and format of PW1 (user) Bit 17 = max. length, for PIN format 2 always '08' (real PIN length up to 12 digits) Bit 8 = 0 for UTF8 passwords 1 for PIN block format 2 3rd byte: max. length of Resetting Code (RC) for PW1 4th byte: max. length and format of PW3 (admin), see PW1 20 (dec.) Fingerprint (binary) for signature key, format according to RFC (dec.) Fingerprint (binary) for decryption key 22

23 Tag C9 CA CB CC CE Format Length 20 (dec.) 20 (dec.) 20 (dec.) 20 (dec.) 4 CF D0 D / 32 D2 16 / 32 D3 D5 0 / 8 xx 16 / 32 D6 02 D7 02 D8 02 F4 C var. Description Fingerprint (binary) for authentication key 1st CAFingerprint in list (binary) 2nd CAFingerprint in list (binary) 3rd CAFingerprint in list (binary) Generation date/time of signature key (Big Endian, format according to RFC 4880 Generation date/time of decryption key (Big Endian) Generation date/time of authentication key (Big Endian) Optional DO (announced in Extended capabilities) for M. MKeyENC for cryptogram (16 or 32 bytes in case of AE128/256). The stored MKey shall match the announced algorithm in Extended capabilities. Optional DO (announced in Extended capabilities) for M. MKeyMAC for cryptographic checksum (16 or 32 bytes in case of AE128/256). The stored MKey shall match the announced algorithm in Extended capabilities. Resetting Code, 0 or 8 xx bytes (dec.), binary Optional DO (announced in Extended capabilities) for PO:DEC with AE (32 bytes dec. in case of AE256, 16 bytes dec. in case of AE128). User Interaction Flag (UIF) for PO:CD (optional): If not supported, DO is not available. First byte = : UIF disabled (default) 01: UIF enabled 02: UIF permanently enabled (optional, a PUT DATA command shall abort if the old content is 02. Changing of a value 02 may be only possible with a factory reset Terminate/Activate). econd byte = Content from General feature management ('20' for button/keypad) UIF for PO:DEC (optional): ee UIF for PO:CD UIF for PO:AUT (optional): ee UIF for PO:CD Optional DO (announced in Extended capabilities) for M. Container for both M keys (ENC and MAC) with Tags D1 and D2. Useful for updating or deleting both keys simultaneous. 23

24 4.4.3 DOs in Detail The following chapter describes some DOs in detail, especially the application specific DOs Private Use These optional DOs can be used by the card holder, administrator or any application for proprietary data (e. g. password list). The difference between the DOs are the access conditions. The presence and maximum length of the DOs is announced in Extended capabilities Name This interindustry data element consists of 0 to 39 bytes, each byte is a character from IO (Latin 1) alphabet (identical to 7bitUACII for characters < 80). The data element consists of surname (e. g. family name and given name(s)) and forename(s) (including name suffix, e. g., Jr. and number). Each item is separated by a < filler character (3C), the family and forename(s) are separated by two << filler characters Language Preferences This data element consists of 1 to 4 pairs of bytes (e. g. 2 bytes or 6 bytes) with coding according to IO 6391, ACII lower case (e. g. de = german; en = english; nl = dutch; fr = french). At least one entry (2 bytes) should be present, the first entry has highest priority. The information can be used by the terminal for the user interface (e. g. language of text) ex This data element of 1 byte (binary) represents the ex of a person according to IO The following values are defined for the : Male Female Not announced The terminal can use the information for the user interface. 24

25 User Interaction Flag The optional feature User Interaction Flag adds a special behaviour to the related commands. If the flag is enabled (or permanently enabled) and a button or keypad is present, the related function will only run if a special button (on a keypad ENTER button) on the card or device is pressed by the user. This is a security function against viruses/trojans that try to call the functions on the card without knowledge of the user. The flags are evaluated by the card and can be changed by the card holder with the admin password (optional). Cards may support a permanently enabling for a flag, in that case the value cannot be changed any more (except factory reset). If the user did not finish the action (abort, timeout) the card should answer with Extended Capabilities The Extended capabilities consists of 10 bytes (dec.) with the following meaning. The first byte is a table that indicates additional features to the terminal. A set bit (1) means that the function is available, a value equalling zero means that the function is not available. Bits can be set simultaneous. Coding of byte 1 of Extended capabilities: b8 1 b7 1 b6 b5 b4 b3 b b1 Meaning ecure Messaging supported upport for GET CHALLENGE The maximum supported length of a challenge can be found in Extended capabilities. upport for Key Import PW tatus changeable (DO C4 available for PUT DATA) upport for Private use DOs ( ) Algorithm attributes changeable with PUT DATA PO:DEC supports AE 0 RFU 25

26 The other bytes are coded as follows: Byte 02 Length A 01 Value ecure Messaging Algorithm 01 = AE 128 bit, dec. 02 = AE 256 bit, dec. If M is not supported (see 1st byte), the coding is Maximum length of a challenge supported by the command GET CHALLENGE (unsigned integer, Most ignificant Bit... Least ignificant Bit). If GET CHALLENGE is not supported (see 1 st byte), the coding is Maximum length of Cardholder Certificates (DO 7F21, each for AUT, DEC and IG), coded as unsigned integer (Most ignificant Bit... Least ignificant Bit). Maximum length of special DOs (Private Use, Login data, URL), coded as unsigned integer (Most ignificant Bit... Least ignificant Bit). PIN block 2 format 0 = not supported 1 = supported RFU () 26

27 Algorithm Attributes This DO announces information related to the supported algorithm of the card. The terminal shall use this information for the key import functionality (if available). The formats are used by the key generation in the card and are also related to the output format of the corresponding command. The content of the DO is optionally changeable (announced in Extended capabilities) with PUT DATA. This is useful if the card supports several algorithms or different key length. The attributes can be changed independent for each key, so it is possible for example to use different key length for signing and decrypting. A card should reject unsupported values in the DO. The supported values are manufacturer specific, please ask your card vendor for the correct parameters if the card supports changing of the attributes. If the attributes of an existing key are changed and do no longer match with the stored key, the card should delete this key internally or prevent it from usage. RA: Byte 01 Length Value Algorithm ID (RFC 4880) 01 = RA (Encrypt or ign) Length of modulus n in bit (e. g bit decimal = 08), binary Length of public exponent e in bit (e. g. 32 bit decimal = 20), binary Format of private key = standard (e, p, q) 01 = standard with modulus (n) 02 = crt (Chinese Remainder Theorem) 03 = crt with modulus (n) ECDA: Byte 01 Length xx var. Value Algorithm ID (RFC 4880 and 6637) 19 = ECDA for PO:CD and INTAUT 18 = ECDH for PO:DEC OID of relevant curve, binary (see annex) 27

28 upported algorithms An OpenPGP smart card V3.0 or higher shall support the following algorithms with their specific details. Mandatory: RA 2048 or higher for PO:CD, PO:DEC and INTERNAL AUTHENTICATE Optional: ECDA 256 bit or higher for PO:CD and INTERNAL AUTHENTICATE ECDH 256 bit or higher for PO:DEC AE 128 bit or higher for ecure Messaging and/or PO:DEC For ECDA/ECDH the following curves are recommended (EN ): Domain parameters standardized by EC 2: Recommended Elliptic Curve Domain Parameters", Version 2.0, by Certicom or ECC Brainpool working group. From this recommendation the following curves should be used for an OpenPGP smart card and will be available in common smart card products: The prime field curves ansix9p256r1 ansix9p384r1 ansix9p521r1 from [ANI X9.62], compliant with [FIP1863] and brainpoolp256r1 brainpoolp384r1 brainpoolp512r1 from [RFC5639]. At least one of this curves shall be supported by an OpenPGP smart card if EC is available. Details of the curve parameters can be found in the annex. 28

29 Private Key Template If the card supports key import (see Extended Capabilities), the terms of the corresponding private key are coded in the following way. The function does not matter how the key is stored in the card internally. The function does not set the value of the corresponding fingerprint. The key import uses a PUT DATA command with odd IN (DB) and an Extended header list (DO 4D) as described in IO The DOs in the Extended Header list start with a Control Reference Template (CRT) of the referenced key. Digital signature: Confidentiality: Authentication: B6 (Tag, Length) B8 A4 The next DO consists of a Cardholder private key template (7F48), that describes the input and the length of the content of the following DO. The last DO (Cardholder private key, 5F48) represents a concatenation of the key data elements according to the definitions in DO '7F48'. The order of the DOs is mandatory (the card may support any order), xx means a length field (1, 2 or 3 bytes). Unnecessary DOs in between DO 7F48 should be stripped off (see format of private in Algorithm attributes). 4D xx Extended Header list for RA B6 or B8 or A4 Control Reference Template to indicate the private key 7F48 xx 5F48 xx Cardholder private key template 91 xx Public exponent: e key format: standard and crt 92 xx Prime1: p standard and crt 93 xx Prime2: q standard and crt 94 xx PQ: 1/q mod p crt 95 xx DP1: d mod (p 1) crt 96 xx DQ1: d mod (q 1) crt 97 xx Modulus: n optional for standard and crt Concatenation of key data as defined in DO 7F48 29

30 everal chips for smart cards support only one coding for the Public exponent (e. g dec.). The card may reject an imported key, if e does not match the internal requirements. But the card shall accept dec. (0101) as value for e. ome chips are not able to calculate n from p and q. In that case the modulus can be integrated in the import. This feature is announced in 'Algorithm attributes'. The length of the key data shall match the values given in the DO 'Algorithm attributes' (C1 C3). E. g., if the Modulus n has a length of 2048 bit (dec.), then p and q have a fixed length of 1024 bits each. 4D xx Extended Header list for ECDA and ECDH B6 or B8 or A4 Control Reference Template to indicate the private key 7F48 xx Cardholder private key template 92 5F48 xx xx Private key Concatenation of key data as defined in DO 7F48 The private key for EC is always stored in bigendian format and zeropadded to the adjusted underlying field size. The adjusted underlying field size is the underlying field size that is rounded up to the nearest 8bit boundary. In case of a signature key (CRT B6), the card internally resets the signature counter to zero Length Field of DOs According to IO the length field in TLVstructures has the following format: Number of bytes 1 2 First byte 7F econd byte FF Third byte FFFF Value (dec.)

31 5 ecurity Architecture All commands and data of a smart card are under control of the security of the card operating system. IO defines mechanisms, attributes (e. g. in FCP) and environments for security purposes. Because this features are quite complex and may differ from card to card (depending on mask developer), the does not evaluate security related items of a card. This chapter is informative for the card developer and defines the access conditions for all commands and data objects of the application in a common way. The described security features are mandatory for the card, but the coding or the way of implementation is up to the card developer, manufacturer or personaliser. Private keys and passwords shall not be readable from the card with any command or function. Commands and data have access conditions to be fulfilled. The following tables show all access conditions for the. READ is a synonym for all functions and commands of the operations system that present data to the external world, WRITE is a synonym for all functions and commands that change data in the Eeprom of the chip. If constructed DOs are processed, the access conditions of each single DO shall be fulfilled. 31

32 Access conditions for relevant commands: Command ELECT (DATA) GET (NEXT) DATA Access condition Always Various VERIFY CHANGE REFERENCE DATA REET RETRY COUNTER Always Always VERIFY of PW3 or Resetting Code Various PUT DATA GENERATE AYMMETRIC KEY PAIR PO: COMPUTE DIGITAL IGNATURE PO: DECIPHER INTERNAL AUTHENTICATE GET CHALLENGE TERMINATE DF Always (read pubkey) VERIFY of PW3 (generate keypair) VERIFY of PW1 VERIFY of PW1 VERIFY of PW1 Always VERIFY of PW3 or Always if PW3 is blocked ACTIVATE FILE Always Other commands Various Description Depending on Data Objects Depending on Data Objects With PW no. 81 With PW no. 82 With PW no. 82 If PW3 is blocked or not usable (e. g. eeprom error), the access condition is always. Has only affect if the application is in termination state. e. g. commands for personalisation Access conditions for Data Objects: Data Object Private use (0101) Private use (0102) Private use (0103) WRITE Verify PW1 Verify PW3 Verify PW1 AID (4F) READ Always Always Verify PW1 Verify PW3 Always Login data (5E) Name (5B) Language preference (5F2D) ex (5F35) URL (5F50) Always Always Always Always Always Verify PW3 Verify PW3 Verify PW3 Verify PW3 Verify PW3 Private use (0104) Description With PW no. 82 With PW no. 82 Verify PW3 Never Writing possible only during personalisation (manufacturer) 32

33 Data Object Card holder private key (5F48) READ Never WRITE Verify PW3 Cardholder certificates (7F21) DCounter (93) Always Always Verify PW3 Never Extended capabilities (C0) Always Never Algorithm attributes (C1 C3) PW1 tatus bytes (C4) Always Always Verify PW3 Verify PW3 Fingerprints (C5, C7 C9) CAFingerprints (C6, CA CC) Generation date/time of key pairs (CD D0) MKeyENC (D1) MKeyMAC (D2) Resetting Code (D3) AEKey for PO:DEC (D5) MKeyContainer (F4) General feature management (7F74) Extended length information (7F66) Always Always Always Verify PW3 Verify PW3 Verify PW3 Never Never Never Never Never Always Verify PW3 Verify PW3 Verify PW3 Verify PW3 Verify PW3 Never Always Never User Interaction Flag PO:CD (D6) User Interaction Flag PO:DEC (D7) User Interaction Flag PO:AUT (D8) Always Verify PW3 Always Verify PW3 Always Verify PW3 Description Relevant for all private keys in the application (signature, decryption, authentication) Internal Reset during key generation Writing possible only during personalisation Only 1st byte can be changed, other bytes only during personalisation In case that the card supports ecure Messaging, a correct command in M mode is equivalent with reaching the access condition for PW3 (Verify PW3). 33

34 6 Historical Bytes Historical bytes are part of the ATR (Answer To Reset) from a card with contacts, the format byte (T0) indicates the presence of Historical bytes in bits 1 4, according to IO An alternative way of reading Historical bytes is a special DO with the Tag '5F52'. Because not all cards provide Historical bytes with an appropriate content, the OpenPGP application uses this DO. In the Historical bytes the presence of the DOs 'Card service data byte' and 'Card capabilities' are relevant. The DO is coded according to IO The DO 'Historical bytes' ('5F52') is part of the Application related data and can be read with the GET DATA command from within the OpenPGP card application. It is relevant for the application and may differ from Historical bytes in the ATR. The first Historical byte is the "category indicator byte". If the category indicator byte is set to '', '10' or '80', then the format is according is IO. Any other value indicates a proprietary format. The assumes a category indicator byte set to ''. The remaining Historical bytes consist of optional consecutive COMPACTTLV data objects followed. The last 3 bytes of the Historical bytes are a status indicator byte and two processing status bytes W1/W2 (normally '90'). The status indicator byte is evaluated by the as follows: = No information given Card does not offer life cycle management, commands TERMINATE DF and ACTIVATE FILE are not supported 03 = Initialisation state can be reset to default values with an ACTIVATE FILE command 05 = Operational state (activated) Card supports life cycle management, commands TERMINATE DF and ACTIVATE FILE are available The COMPACTTLV format has a Tag in the first nibble of a byte (bit 58) and a length in the second nibble (bit 14). For the a TL with '73' is relevant, it announces a DO 'Card capabilities' with 3 bytes. In addition a TL with '31' announces a DO 'Card service data' with 1 byte, that is interpreted by the also. Other DOs may appear. 34

35 6.1 Card Capabilities (73) This interindustry data element consists of three software function tables (1 byte each) according to IO The first software function table indicates selection methods supported by the card. The second software function table is the "data coding byte". The third software function table indicates the ability to chain commands, the support for Extended Lc and Le fields and to handle logical channels. A set Bit (1) means that the function is available (unless otherwise specified), a value equal zero means that the function is not available. Bits can be set simultaneous. For the only the third table (byte 3) is relevant (yellow marked functions should be evaluated in this version). Command chaining, length fields and logical channels (third byte): b8 x b7 x b6 x b5 b4 b3 x x y b2 b1 z t Meaning Command chaining Extended Lc and Le fields Extended Length Information in EF.ATR/INFO Logical channel number assignment Maximum number of logical channels If Extended Length is announced in bit 7, then the DO Extended length information shall be present in the OpenPGP card application. 35

36 6.2 Card service data (31) This interindustry data element consists of 1 byte according to IO A set Bit (1) means that the function is available (unless otherwise specified), a value equal zero means that the function is not available. Bits can be set simultaneous. For the OpenPGP application yellow marked functions should be evaluated in this version. Command chaining, length fields and logical channels (third byte): b8 x b7 x b6 x b5 x b4 b3 b2 b1 x x x x Meaning Application election by full DF name (AID) Application election by partial DF name DOs available in EF.DIR DOs available in EF.ATR/INFO hall be set to 1, if Extended Length is supported EF.DIR and EF.ATR/INFO access services by the GET DATA command (BERTLV) hall be set to 010, if Extended Length is supported Card with MF (0) Card without MF (1) 36

37 7 Commands The is based on the functionality of IO 78164, 8 and 9. Thus the standard O commands are available to the 'external environment'. 7.1 Usage of IO tandard Commands The following table shows all standard commands of an IO operating system, which are used by the. Only the given subsets (P1/P2) of a command shall be implemented, however the card may provide other functions. Command ELECT IN A4 ELECT DATA A5 GET DATA CA GET NEXT DATA CC VERIFY CHANGE REFERENCE DATA REET RETRY COUNTER Comment AID = 116 Byte (partial AID is recommended) P2 = for first or only occurrence 01/02 04 P1 = Occurrence number of /03 DOs with same tag (DO 7F21) P2 = First or only occurrence of a DO after skipping P1 occurrences and Return the data control Information (DO 62) xx xx upported as defined for specified DOs xx xx upported as defined for specified DOs 81/82/83 Local PW1 or PW3 81/83 Change of PW1 or PW3 2C /02 81 DA or xx DB 47 80/81 xx PUT DATA GENERATE AYMMETRIC KEY PAIR PERFORM ECURITY OPERATION (PO) COMPUTE DIGITAL IGNATURE P1 04 P2 2A xx xx 2A 9E 9A Resets the retry counter of PW1 and sets a new value for PW1. In the command data the new PW1 is present. upported as defined for specified DOs P1 = 80: Generation of internal private key, public key in response (DO 7F49) P1 = 81: Reading of actual public key Relevant key is addressed by a CRT in the command data As defined in the next lines Input are plain data (e. g. hash code), length shall match the algorithm and key length of the 37

38 Command IN P1 P2 Comment card, digital signature in response for RA 2A INTERNAL AUTHENTICATE 88 GET REPONE C0 GET CHALLENGE 84 TERMINATE DF E6 ACTIVATE FILE 44 Input: Padding indicator byte ( or 02) and encrypted data (length of encrypted data shall match algorithm and key length) for RA; DO for ECDH Response: Plain data / hared secret Authentication input related to algorithm Used under T=0 and for retrieving long DOs with GET DATA under any protocol Fully supported (Le defines length of random number), optional command. If supported the card shall provide any length according to simple Le. If extended Le is supported the maximum length is announced in Extended capabilities The command puts the application into the termination state. After termination only ELECT and ACTIVATE FILE are available In the the termination state is equivalent to the initialisation state. An ACTIVATE FILE command in this stage resets all DOs to default values and sets the application into the operational state. The usage of this command in operational state (not terminated) has no effect to any data DECIPHER Additional commands for production, personalisation and other applications are out of scope of this specification. 38

39 7.2 Commands in Detail The following section describes some of the commands in more detail. In all examples short Lc/Le is used. If the card provides extended Lc/Le than the terminal may extend the fields to a length of 2 or 3 bytes. Commands that support ecure Messaging (option) are marked with a Class byte of 0C ELECT With this command the in the terminal selects the corresponding application on the card. Only the significant bytes of the AID are presented in the command data. Possible response data (FCI) don't need to be evaluated by the application. A valid ELECT of the sets the curconstructeddo pointer to the Virtual Root DO and adds all data objects in the application to the current template. The curdo ponter is undefined, so a following GET/PUT DATA command will always reference the first occurrence of a DO. Command: CLA IN P1 P2 Lc Data field Le A D Response: Data field W1W2 FCI or empty 90 or specific status bytes 39

40 7.2.2 VERIFY With this command one of the passwords of the application is verified. PW1 has two modes and can be used with 2 different numbers (in P2). PW 1 with P2 = 81 sets the access conditions for a PO:CD command only. Depending on the PW1 tatus byte (see Extended capabilities) this access condition is only valid for one PO:CD command or remains valid for several attempts. PW1 with P2 = 82 sets the access condition for several other functions and remains valid up to a reset or ELECT of a different application. Command: CLA IN P1 P2 Lc Data field Le / 0C (PW1) or 82 (PW1) or 83 (PW3) xx (min. 06 for PW1, min. 08 for PW3, max. see DO C4 ) in case of UTF8 format 08 in case of PIN block format 2 Corresponding PW in correct format Empty (means not present in command) Response: Data field W1W2 None 90 or specific status bytes PIN block format 2 This format can be set in the PW status bytes (optional, announced in Extended capabilities) and has the following structure (taken from IO 95643): 40

41 7.2.3 CHANGE REFERENCE DATA With this command the passwords of the application can be changed. In compliance with EN only one P1 variation from IO is defined for signature cards. The command can be accessed without restrictions, the actual PW is part of the command data and will be verified first by the card. The length of the existing password is known in the card, so that neither a delimiter nor padding for filling up fixed formats is necessary for UTF8. The length of the new UTF8 password therefore computes L new = Lc Lold. PIN block format 2 passwords have a fixed length of 8 bytes. Command: CLA IN P1 P2 Lc Data Field Le / 0C (PW1) or 83 (PW3) xx Actual PW + New PW Length of new UTF8 PW: min. 06 for PW1, min. 08 for PW3 For max. length see DO C4 For PIN block format 2 two blocks (8 bytes each) for old and new PIN are concatenated Empty (means not present in command) Response: Data field W1W2 None 90 or specific status bytes 41

42 7.2.4 REET RETRY COUNTER With this command the error counter and the value of PW1 can be resetted, that means the new value is stored and the error counter is set to the default value (3). REET RETRY COUNTER can be used after correct verification of PW3 (P1 = 02) or by presenting the Resetting Code (DO D3) in the command data (P1 = ). Usage of secure messaging is equivalent to PW3. The length of the Resetting Code is known in the card, so that neither a delimiter nor padding for filling up fixed formats is necessary for UTF8. The length of the new UTF8 password therefore computes L new = Lc LRC. PIN block format 2 passwords have a fixed length of 8 bytes. Command: CLA IN P1 P2 Lc Data field Le / 0C 2C / (PW1) xx (min. 06 for PW1, max. see DO C4 ) New PW (P1 = 02) Resetting Code + New PW (P1 = ) Empty (means not present in command) Response: Data field W1W2 None 90 or specific status bytes 42

43 7.2.5 ELECT DATA With this command a DO in the current template can be selected. The command is needed to address DOs with several instances with the same Tag (e. g. 7F21, Card holder certificate). A successful command sets the curdo pointer to the addressed DO and makes it the current DO, a following GET DATA or PUT DATA will access this current DO. etting the first instance (P1 = ) will work with every accessible DO, higher values will only work for DOs with several instances. Possible response data (Control Parameter = CP) don't need to be evaluated by the application. Command: CLA IN P1 A5 xx = Occurrence number of an instance to skip 02 is defined for the P2 04 = First occurrence after skipping P1 occurrences with CP in response Lc xx Data 60 xx (General reference DO) Field 5C xx (Tag list) Tag of the DO to be selected Le Response: Data field W1W2 Control Parameters (CP) or empty 90 or specific status bytes Examples: ' elects the 1st occurrence of the Card holder certificate (AUT) A C 02 7F21 ' elects the 2nd occurrence of the Card holder certificate (DEC) A C 02 7F21 ' elects the 3rd occurrence of the Card holder certificate (IG) A C 02 7F21 43

44 7.2.6 GET DATA With this command DOs can be read from the card. The Tag (simple or constructed) is given in P1/P2 (e. g. 5F50 for URL or 6E for Application Related Data). For simple DOs only the value is in the response field (e. g. 5F50 = URL returns a byte string representing the URL without leading Tag/Length). For constructed DOs all values returned are encapsulated with Tag/Length (e. g. 65 = Cardholder Related Data returns the concatenation of following DOs (L = Length): 5B L Name 5F2D L Language Preferences 5F35 L ex). If the DO is longer than the maximum supported length for a response of a card, then the card may answer with status bytes 61xx and return only the first part of the data, xx indicate the remaining data in the card. The data may be truncated at any position and shall be concatenated later in the terminal. The terminal can read the missing data with a following GET REPONE command and Le = (or for extended Le). This can be repeated several times (another status byte 61xx). The reading of data is complete if any command (GET DATA or GET REPONE) answers with status bytes 90. A valid GET DATA makes the first occurrence of the addressed DO to the current DO, if the curdo pointer was undefinied. Otherwise (e. g. previous ELECT DATA) the current DO with the addressed Tag is returned. Command: CLA IN P1 P2 Lc Data Field Le / 0C CA xx ( if Tag has a length of only one byte) xx Empty None Response: Data field W1W2 Addressed data or DOs (maybe partially) 90 or 61xx or specific status bytes 44

45 7.2.7 GET NEXT DATA With this command other instances of DOs with the same Tag can be read from the card. The command is only valid for the user certificate (7F21) that has 3 occurrences. The command can be used only of the curdo pointer is still set to a valid occurrence of DO '7F21'. It selects the next occurrence automatically (internal ELECT DATA) and returns the data field of the DO. With the following commands in a sequence all certificates can be read from the card: GET DATA with P1P2= 7F21 returns the 1st occurrence (AUT certificate) GET NEXT DATA with P1P2= 7F21 returns the 2nd occurrence (DEC certificate) GET NEXT DATA with P1P2= 7F21 returns the 3rd occurrence (IG certificate) This way is quicker than reading all certificates with ELECT DATA and following GET DATA, but it is still possible to do it in that way. If you only want to read the 3rd occurrence (IG certificate), for e. g., then a ELECT DATA with following GET DATA is more useful. Command: CLA IN P1 P2 Lc Data Field Le / 0C CC 7F 21 Empty None Response: Data field W1W2 Addressed DO 90 or 61xx or specific status bytes 45

46 7.2.8 PUT DATA With this command DOs can be written to the card. The Tag is given in P1/P2 (e. g. 5F50 for URL or 5B for Name). For simple DOs only the value is in the data field (without leading Tag/Length). The command can only be used after correct presentation of PW3 (except DO 0101 and DO 0103 after correct verification of PW1 with No. 82). For key import in compliance with IO an Extended header list is supported with an odd IN of the command. In that case P1/P2 has the value 3FFF (references the current DF for the DOs in the Extended header list). An empty data field (Lc absent) deletes the content of a DO with variable length (e. g. URL), but not the DO itself. A valid PUT DATA makes the first occurrence of the addressed DO to the current DO, if the curdo pointer was undefinied. Otherwise (e. g. previous ELECT DATA) the content of the current DO with the addressed Tag is replaced. Command: CLA IN P1 P2 Lc Data Field Le / 0C DA / DB xx = if Tag has a length of one byte only = 3F in case of odd IN xx (FF in case of odd IN) xx or empty Addressed data or Extended header list or empty Empty Response: Data field W1W2 None 90 or specific status bytes 46

47 7.2.9 GET REPONE This command is needed under T=0 for some command cases according to IO and under any protocol (e.g. T=1) for receiving long data that cannot be transmitted in one response. After receiving status bytes with 61 xx, the terminal should send a GET REPONE command with xx or in the Le field. Command: CLA IN P1 P2 Lc Data field Le / 0C C0 Empty Empty (xx given in previous W2) Response: Data field W1W2 Data 90 or 61xx or specific status bytes 47

48 PO: COMPUTE DIGITAL IGNATURE The command for digital signature computation is shown in the table below. The hash value (ECDA) or the DigestInfo is delivered in the data field of the command. ignature key as well as signature algorithm and the related DigitalignatureInput formats are implicitly selected. The command is only possible after correct presentation of PW1 with No. 81. The command internally checks the PW1 tatus byte DO (first byte), if the value is, then the access condition (No. 81 of PW1) is reset and the PW has to be verified again for the following command. It is possible to use the command outside of the OpenPGP environment (e. g. MIME), for that reason it is possible to store a related certificate (Tag 7F21) as 3rd occurrence into the card. Command: CLA IN P1 P2 Lc Data field Le 2A 9E 9A Length of subsequent data field Data to be integrated in the DI: hash value or DigestInfo Response: Data field W1W2 Digital signature 90 or specific status bytes The DI format for RA: According to PKC #1 the DI is generated internally by the card and has the following structure: Description tart byte Block type Padding string (P) eparator Data field Length 1 1 N3L 1 L Value 01 FF... FF DigestInfo 48

49 In compliance with PKC #1, the card checks that the DigestInfo in the command data field is not longer than 40% of the length of the modulus of the signature key, otherwise the command is rejected. DI for ECDA: The DI consists of the hash value which was calculated (28, 32, 48 or 64 bytes, dec.). If the required DI for the computation is longer than the hash value, then the DI is filled with leading zero bits by the card Hash Algorithms The following hash algorithms are supported by RFC 4880 and can be used as input in the DI. Older HA1 and RIPEMD160 are not allowed for DI in actual standards and should be avoided for the OpenPGP smart card also. However the card may not check the integrity of a DI. Hash algorithm Length of hashcode (dec.) HA HA HA HA

50 DigestInfo for RA The following tables show the contents of defined DigestInfos for RA. The card may not check the correctness of the DigestInfo. HA224: Tag Length Value Description 30 2D Tag/Length of equence 30 0D Tag/Length of equence OID of the HA224 { } 05 TLV coding of ZERO 04 1C xx...xx hashcode HA256: Tag Length Value Description Tag/Length of equence 30 0D Tag/Length of equence OID of the HA256 { } 05 TLV coding of ZERO xx...xx hashcode HA384: Tag Length Tag/Length of equence 30 0D Tag/Length of equence OID of the HA384 { } 05 TLV coding of ZERO xx...xx hashcode Value Description 50

51 HA512: Tag Length Tag/Length of equence 30 0D Tag/Length of equence OID of the HA512 { } 05 TLV coding of ZERO xx...xx hashcode Value Description 51

52 PO: DECIPHER The command is used by the application as key decipherment service. The command can be used after correct presentation of PW1 (with No. 82) only. For confidential document exchange, the following scheme is applied: The key transport is organised by enciphering the content encryption key with the receivers public key. The document enciphering is done with a symmetrical algorithm (e. g. AE). The card is not involved in the enciphering of the document. The software computes the content encryption key, enciphers the document and finally enciphers the content encryption key by using the receivers public key. The card performs a key decryption applying the private key for decryption in a DECIPHER command to the cryptogram contained in the data field of the command. By option (announced in Extended capabilities) the card supports the decryption of a plain text with an AEkey stored in a special DO (D5). This is useful if no certificate or public key exists and the external world has a common secret with the card. The functionality can be used e. g. for storing an encrypted transport key or seed on a flash card/stick or hard disc, only the relevant card is able to decrypt the secret if the AEkey is deleted in the outside world after encryption and storing into the card. In case of the RA algorithm the command input (except padding indicator byte) shall be formatted according to PKC#1 before encryption: Description tart byte Block type Padding string (P) eparator Data field Length 1 1 N3L 1 L Value 02 Nonzerorandombytes Message 52

53 P is a byte string consisting of randomly generated nonzero bytes. The length of P shall be at least 8 bytes. The formatted string shall consist of N bytes where N is the length of the modulus of the private key for decryption. The Padding indicator byte and the encrypted message is given to the command in the command data. The card decrypts all bytes after the padding indicator byte, checks the conformance of correct PKC#1 padding and returns the plain text (length = message) in the response. In case of the AE algorithm the command input (except padding indicator byte) shall be exact 16 bytes. A key shall be present in DO (D5), the Padding indicator byte (02) and the encrypted message is given to the command in the command data. The card decrypts all bytes after the padding indicator byte and returns the plain text (16 bytes) in the response. In case of ECDH the card supports a partial decrypt only. The input is a cipher DO with the following data: A6 xx Cipher DO 7F49 xx Public Key DO 86 xx External Public Key The external public key for ECDH consists of of two raw bigendian integers with the same length as a field element each. In compliance with EN the format is 04 x y where the first byte (04) indicates an uncompressed raw format. The card shall abort the command if the given OID does not match the defined curve for the command (see Algorithm attributes). With its own private key and the given public key the card calculates a shared secret in compliance with the Elliptic Curve Key Agreement cheme from DiffieHellman. The shared secret is returned in the response, all other calculation for deciphering are done outside of the card. 53

54 Command: CLA IN P1 P2 Lc Data field Le 2A 80 = Return plain value 86 = Enciphered data present in the data field xx = Length of subsequent data field Padding indicator byte () for RA or (02) for AE followed by cryptogram Cipher DO 'A6' for ECDH Response: Data field W1W2 Plain data (RA or AE) / hared secret (ECDH) 90 or specific status bytes It is possible to use the command outside of the OpenPGP environment, for that reason it is possible to store a related certificate (Tag 7F21) as 2nd occurrence into the card. 54

55 INTERNAL AUTHENTICATE The INTERNAL AUTHENTICATE command can be used for Client/erver authentication. The usage is up to the terminal, the card only provides this command for asymmetric algorithms. The input data shall be an Authentication Input (AI) compliant with PKC#1 for RA, the card does an internal PKC#1padding and calculates a signature with the corresponding secret key for authentication. For ECDA the input is a hash only. The command can be used after correct presentation of PW1 (with No. 82) only. In compliance with PKC #1, the card checks in case of RA that the AI in the command data field is not longer than 40% of the length of the modulus of the signature key, otherwise the command is rejected. PKC#1Padding for Authentication Input used with RA: Description tart byte Block type Padding string (P) eparator Data field Length 1 1 N3L 1 L Value 01 FF...FF Authentication Input (AI) The resulting input for the signature in case of RA has the length N. The card calculates the signature with the private key for authentication: sign(k Aut)[ 01 P AI] and returns the result as authentication data in the response. For ECDA the AI consists of the hash value which was calculated (28, 32, 48 or 64 bytes, dec.). If the required AI for the computation is longer than the hash value, then the AI is filled with leading zero bits by the card. 55

56 Command: CLA IN 88 = INTERNAL AUTHENTICATE P1 P2 Lc xx = Length of subsequent data field Data Authentication Input (AI) Field for RA: Lc <= 0,4 * N, e.g.: Lc <= 102 for 2048 bit modulus for ECDA: Hash value (values are decimal) Le Response: Data field W1W2 ignature 90 or specific status bytes 56

57 Client/erver Authentication This specification covers only the case where the card performs a digital signature computation applying the private key for authentication in an INTERNAL AUTHENTICATE command to the authentication input contained in the data field of the command after formatting the input. The mechanism can be used, for example, with ecure hell (H), PK Kerberos, L/TL or WTL. All these protocols base on the same cryptographic algorithms. In particular they are all using PKC #1 padding format in the case of RA. In the above example (taken from EN ), client/server authentication establishes a secured channel between a remote server and a PC. The ICC will be used as a cryptographic toolbox in order to provide the cryptographic functionality to the PC. If a process needs a certificate from the card that is not provided by OpenPGP (e. g. x.509), then it can be stored in the DO 'Cardholder certificate' (7F21 AUT) as 1st occurrence. 57

58 GENERATE AYMMETRIC KEY PAIR This command either initiates the generation and storing of an asymmetric key pair, i. e., a public key and a private key in the card, or returns the public key of an asymmetric key pair previously generated in the card or imported. The card should use dec. (101 bin.) as default value for e, but other values are accepted by the outside world. In case of key pair generation the command does not set the values of the corresponding fingerprint. After receiving the public key the terminal has to calculate the fingerprint and store it in the relevant DO. The generation of a key pair for digital signature resets the digital signature counter to zero (). The command can only be used after correct presentation of PW3 for the generation of a key pair. Reading of a public key is always possible. Command: CLA IN P1 P2 Lc Data field Le / 0C = Generation of key pair 81 = Reading of actual public key template 02 CRT for relevant function Response: Data field Public key as a set of data objects W1W2 90 or specific status bytes Defined CRTs (Control Reference Template) for the command (generation of key pair or reading of public key). Digital signature: Confidentiality: Authentication: B6 (Tag, Length) B8 A4 58

59 Defined DOs for response (xx = Length): 7F49 xx et of public key data objects for RA 81 xx Modulus (a number denoted as n coded on x bytes) 82 xx Public exponent (a number denoted as v, e.g dec.) et of public key data objects for ECDA/ECDH 86 xx Public key (a point denoted as PP on the curve, equal to x times PB where x is the private key, coded on 2z or z+1 bytes) The public key for ECDA/DH consists of of two raw bigendian integers with the same length as a field element each. In compliance with EN the format is 04 x y where the first byte (04) indicates an uncompressed raw format. A card may send other DOs in compliance with IO 78168, but only the mandatory DOs defined above need to be evaluated. 59

60 GET CHALLENGE This optional command (announced in Extended Capabilities) generates a random number of the length given in Le. It is a service to the terminal application because smart cards often generate high sophisticated random numbers by certified hardware. everal smart card implementations have limitations for the length of the random number, so the maximum length is announced in Extended capabilities. The command is mandatory if the cards supports ecure Messaging. Command: CLA IN P1 P2 Lc Data field Le 84 Empty Empty xx (01FF for hort Le, 01maximum for Extended Le) Response: Data field W1W2 Challenge with length xx 90 or specific status bytes 60

61 TERMINATE DF This optional command (announced in Life Cycle tatus indicator in Historical bytes) sets the Life Cycle tatus indicator to 03 and puts the card into initialisation state. The behaviour of the application is similar to the termination state, no commands can be used except ELECT FILE, which return specific status bytes (6285). After a selection an ACTICATE FILE command is possible. That command is designed to renew a card in case of blocked passwords or other problems. The command is allowed after correct verification of PW3 (AdminPW) or secure messaging (M) if PW3 is disabled. If PW3 is blocked or not accessible (e. g. memory failure) and M is disabled, then TERMINATE can be used without access conditions. This prevents the card from any status that makes it unusable. Command: CLA IN P1 P2 Lc Data field Le / 0C E6 Empty Empty Empty Response: Data field W1W2 Empty 90 or specific status bytes 61

62 ACTIVATE FILE This optional command (announced in Life Cycle tatus indicator in Historical bytes) can be used to reset all values (DOs, Keys, PWs etc.) to their default values (after production/ initialisation). The command has effect only, if the life cycle status is in initialisation state (indicator byte set to 03). If the command is used in operational state, it will end with status bytes 90, but nothing in the application will be changed (dummy command). Command: CLA IN P1 P2 Lc Data field Le 44 ICV = RND Empty Empty Empty Response: Data field W1W2 Empty 90 or specific status bytes 62

63 7.3 Command Usage under Different I/O Protocols For the the T=1 protocol (IO 78163) is recommended for cards with contacts. However other protocols (one or more) in a card are possible too. The is designed to run under every protocol (e. g. T=0, contactless) that is provided by the card reader. If contactless protocols (e. g. IO 14443) are implemented, card and reader should support ecure Messaging (e. g. VERIFY) to avoid data tracking 'over the air'. 7.4 Class Byte Definitions For the all standard commands are used with a class byte (CLA) coding according to IO. The following values are defined (CLA 10 and 1C are only relevant if the card supports command chaining). CLA 0C 10 1C Description CLA without M (last or only command of a chain) CLA with M and header authentication (last or only command of a chain) CLA without M (command is not the last command of a chain) CLA with M and header authentication (command is not the last command of a chain) 7.5 ecure Messaging (M) The defines secure messaging with static keys in this version and uses a variant of M from EN with AE without end equence Counter (CBC mode). Command data are encrypted first and then protected by a cryptogram. M is optional and announced in Extended capabilities. Only a subset of the commands may support M (see CLADefinition in the command section). M is designed as a replacement of the AdminPW (PW3) and can be used to change data objects online (helpful for company cards, admin = company; user = employee). It is highly recommended to use M for security related commands (e. g. VERIFY) if the runs in contactless mode, because all data on the interface can be traced easily within a range of several meters. M is defined for the algorithm AE with 128 or 256 bit. The supported algorithm is announced in Extended capabilities, the related keys are stored in the application DOs 'M KeyENC' and 'M KeyMAC'. By default the content of the DOs is empty and M will 63

64 not work. The keys can be set with a PUT DATA command after correct presentation of the AdminPW (PW3). Form that point on all related commands can be used with M. A command with correct M has the same access condition to data in the application than a VERIFY with PW3. If existing keys are replaced with PUT DATA, the card shall use the new values for the calculation of the response. The deletion of Mkeys should be done simultaneous with the DO 'F4', otherwise the functionality of M is undefined. A key is deleted by writing an empty data string with PUT DATA. Rules for M usage: For a command with even IN, any command/response data is encrypted and capsulated in a Tag 87 with padding indicator (01). For a command with odd IN, any command/response data is encrypted and capsulated in a Tag 85 without padding indicator. Commands with response (Le field not empty) have a protected Lefield (Tag 97) in the command data. Commands with response have a protected processing status (Tag 99) in the response. Commands without response (e. g. Case 3) have no processing status and/or MAC in the response field (W1W2 only). All Mcommands have at least an unencrypted MAC (Tag 8E) in the command data field. To protect the M commands against replay attacks, a random number (RND) of 16 bytes is used as Initial Chaining Value (ICV). Before each command with M the external world shall read a RND with 16 bytes from the card (Get Challenge). The last challenge from the card is internally used as ICV and is valid for one command and the response only. Encryption is done first in CBCMode with ICV = RND. MACing is done on the encrypted data with ICV = RND in CMACMode. 64

65 RND APDU command data encryption (even IN) with AE in CBC mode For odd IN the Tag for EDFB is '85' and the padding indication (constant '01') is omitted. 65

66 ICV = RND APDU computation of AE cryptographic checksum in CMAC mode Final APDU command construction 66

67 ICV = RND Response APDU data encryption using AE in CBCmode For odd IN the Tag for EDFB is '85' and the padding indication (constant '01') is omitted. 67

68 ICV = RND Response APDU computation of cryptographic checksum with AE in CMACMode 68

69 Final response APDU contruction 7.6 Logical Channels The does not use logical channels in this version. Channel number zero is assumed for all commands. 69