FINEID - S1 v2.1 Electronic ID Application

Similar documents
FINEID - S1 Electronic ID Application

PUBLIC USER SPECIFICATION BELPIC APPLICATION V2.0

Functional Specification of the OpenPGP application on ISO Smart Card Operating Systems

Functional Specification of the OpenPGP application on ISO Smart Card Operating Systems

FINEID - S4-2 Implementation Profile 2

FINEID - S4-1 Implementation Profile 1

Functional Specification of the OpenPGP application on ISO Smart Card Operating Systems

ACOS5-64. Functional Specifications V1.04. Subject to change without prior notice.

Security Policy for Schlumberger Cyberflex Access 32K Smart Card with ActivCard Applets

Terminal Architecture for PSAM Applications (TAPA) Application Architecture Specification. Version 2.1. February 2001

SmartCards as electronic signature devices Progress of standardization. Helmut Scherzer, CEN TC224/WG16 (Editor) IBM Germany

Technical report. Signature creation and administration for eidas token Part 1: Functional Specification

Card Specification Amendment A March 2004

APDU-Test Card Functional Requirements

PayPass M/Chip 4. Card Technical Specification

Technical report. Signature creation and administration for eidas token. Version 1.0 Release Candidate 6. Version 1.0 Release Candidate 6

EMV 96 Integrated Circuit Card Application Specification for Payment Systems

INTELLIS. Modbus Direct Network Monitor

Workshop Challenges Startup code in PyCharm Projects

04-374r0 SES-2 Define a SAS Expander element 7 November 2004

I N F O R M A T I O N S E C U R I T Y

PKCS #15: Conformance Profile Specification

Displaying SSL Configuration Information and Statistics

Test plan for eid and esign compliant smart card readers with integrated EACv2

ETSI TS V7.1.0 ( )

CEPTEST Application Note

Package PKI. September 16, 2017

MTAT Applied Cryptography

APPENDIX 6. EXTERNAL INTERFACES

The Mobile Finnish Identity Certificate

To use a RFID reader to create commands to communicate with the contactless smart card.

Project Report. Title: Finding and Implementing Auto Parallelization in RSA Encryption and Decryption Algorithm

ACR1281U-C1 USB Dual Interface Reader Application Programming Interface V1.08 Subject to change without prior notice

ETSI TS V ( )

Unless otherwise indicated additions are shown in blue, deletions in red strikethrough, and comments in green.

TO: FROM: DATE: SUBJECT: Revisions General 2.1 The Mismatch does

Java Card Approach to Emulate The Indonesian National Electronic ID Smart Cards

Technological foundation

: Practical Cryptographic Systems March 25, Midterm

Application Note. Web Signing. Document version

GLDA MAO-DOC-TEC-008 v2.28

Summer 2003 Lecture 26 07/24/03

Open Mobile API test specification for Transport API V0.9

FINEID - S4-1 Implementation Profile 1

AMENDMENT ISO/IEC :2005 FDAM 1 FINAL DRAFT

Summary of PGP Services

1 Overview. 2 Changes to SPC-4. T10/ revision 5

AES, DES, and RSA Support (Intended for Domestic Use) SASEBO-W Smart Card OS Specification

Security Proposal for PMCI Standards and Protocols Architecture for Version 1.0 Release Work in Progress Last Updated: 12/17/2018

1 Overview. T10/ revision 0

Table of Contents 1 SSH Configuration 1-1

KMIP 64-bit Binary Alignment Proposal

The next page shows the questions asked in revision 0 of this proposal and the answers supplied by the May SCSI Working Group meeting.

Digital it Signatures. Message Authentication Codes. Message Hash. Security. COMP755 Advanced OS 1

ISO/IEC INTERNATIONAL STANDARD. Identification cards Integrated circuit cards Part 4: Organization, security and commands for interchange

Action List Modify Configuration Mode Commands

EMV Contactless Specifications for Payment Systems

M/Chip Advance V1.1 Personalization Guide

IDPrime MD 830-revB FIPS Cryptographic Module Non-Proprietary Security Policy Level 3

Open Mobile API Test Specification v1.0 Errata Note DRAFT 0.7

CANopen Vehicle Gateway Software Specifications rev 2.01

ETSI TS V7.3.0 ( )

MTAT Applied Cryptography

04-374r2 SES-2 Define a SAS Expander element 13 January 2005

Pretty Good Privacy (PGP

Smart card operating systems

Technical Specification Smart Cards; Extensible Authentication Protocol support in the UICC (Release 9)

Request for Comments: 2537 Category: Standards Track March RSA/MD5 KEYs and SIGs in the Domain Name System (DNS)

Omni Flow Computer Master Driver v1.x Omni Flow Computer Master Modicon Compatible Driver 1.x

Waspmote Encryption Libraries. Programming guide

X12 Implementation Guidelines For Inbound 997 v (I )

Cryptography and secure channel. May 17, Networks and Security. Thibault Debatty. Outline. Cryptography. Public-key encryption

SWG-F D6 MESSAGE IMPLEMENTATION GUIDELINE OF THE UN/EDIFACT SECURE AUTHENTICATION & ACKNOWLEDGEMENT MESSAGE AUTACK. DRAFT 0.6m

How to write a SECA CAM by JF Version 1.00 April 2003

Internet Engineering Task Force (IETF) Category: Experimental Helsinki Institute for Information Technology ISSN: May 2011

MUM. MULTOS Utility Manual. MULTOS Utility Manual. MAO-DOC-TEC-017 v2.10.0

Request for Comments: 3110 Obsoletes: 2537 May 2001 Category: Standards Track. RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS)

TS V1.2.1 ( )

EHAG 125 khz Multitag Reader Module ME-H10101xx

ETSI TS V6.0.0 ( )

basic schemes, memory types: transient vs. persistent, garbage collection basic schemes, system-level vs. user-level transactions

NFC Type 5 / RFID tag IC with 16-Kbit or 64-Kbit EEPROM and protection

EMV Contactless Specifications for Payment Systems

Managed Objects Authenticated Encryption Additional Data Authenticated Encryption Tag Certificate

The English version of this specification is the only normative version. Non-normative translations may also be available.

ACR1251U-A1 USB NFC Reader with SAM

Modbus ASCII Serial Device Driver Help 2009 Kepware Technologies

EMV Contactless Specifications for Payment Systems

esigner Release Notes

RHODE ISLAND Electronic Business Transactions

Digital Certificates Demystified

WatchKey ProX USB Token Cryptographic Module Hardware Version: K023314A Firmware Version:

payshield 9000 Online PIN Delivery Application Note PWPR February 2012

ETSI TS V5.3.0 ( )

MACHINE READABLE TRAVEL DOCUMENTS

PM130 Powermeters Reference Guide ASCII Communications Protocol

EMV Contactless Specifications for Payment Systems

Document T10/ rev. 1

Category: Informational January 2010 ISSN:

Secure UHF Tags with Strong Cryptography Development of ISO/IEC Compatible Secure RFID Tags and Presentation of First Results

Transcription:

FINEID SPECIFICATION 5.12.2011 FINEID - S1 v2.1 Electronic ID Application Application Note 1 Population Register Centre (VRK) Certification Authority Services P.O. Box 70 FIN-00581 Helsinki Finland http://www.fineid.fi

FINEID - S1 / Application Note 1 i Authors Name Initials Organization E-mail Antti Partanen AP VRK antti.partanen@vrk.fi Gemalto GTO Gemalto Document history Version Date Editor Changes Status 1.0 5.12.2011 AP Public edition Final

FINEID - S1 / Application Note 1 ii Table of Contents 1 Management of data when data size is larger than I/O buffer... 1 1.1 CLASS byte coding... 1 1.2 Command chaining mechanism... 1 2 Commands supporting command chaining mechanism... 3 2.1 GET DATA... 3 2.2 Applet version... 5 2.3 PSO: CDS... 6 2.4 PSO: DECIPHER... 7 2.5 PSO: HASH... 8

FINEID - S1 / Application Note 1 1(10) EID2048 Applet: Application Note 1 1 Management of data when data size is larger than I/O buffer 1.1 CLASS byte coding The class byte coding shall be as below: If an error occurs during the check of the CLA byte of an APDU command, the applet must return the status RES_CLA_ERR. 1.2 Command chaining mechanism If indicated for a command (b5 of the class byte), command chaining shall be supported according to ISO/IEC 7816 part 4. The commands that support command chaining are specified later in this application note. If the data field length to send to the application is more than FFh bytes, the data field must be sent by blocks of data of FFh bytes or less. Each block is composed by the same command header (bit 5 of the class byte excepted) and by the block data field. The CLA bit 5 of the last command of a chain shall be set to 0, whereas the bit 5 for all preceding chaining commands shall be set to 1. The command headers are identical in all commands of a chain otherwise the card returns RES_INS_ERR.

FINEID - S1 / Application Note 1 2(10) If the application does not respond with RES_OK to a command of a chain with CLA '1X' (or 9X ), command chaining is aborted. The command is processed only when all the data field has been received by the application (intermediate RES_OK only means correct command format) If the command chaining mechanism is unavailable for a command, the card returns RES_CLA_ERR. Example with a data field of 300d (12Ch) bytes: Data field: M1 to M300 Command header: 00 INS P1 P2 The 2 sent commands could be: (the data field can be truncated anywhere ) 10h INS P1 P2 F0h M1.. M240 (The card must return RES_OK) 00h INS P1 P2 3Ch M241.. M300 (The card processes the command with all the data field) Retrieval of response data longer than 256 bytes In the following use cases the application must return up to 256 bytes plain data plus TL structure so that the total length of the response data exceeds 256 bytes: PSO commands if a 2048-bit key is used. GET DATA command if a 2048-bit key is used. This section defines how these cases shall be treated. The way to retrieve all the outgoing data of such cases consists of a Retrieval sequence A Retrieval Sequence begins by a command sent to the card, A Retrieval Sequence finishes by the last Get Response command sent to retrieve the last outgoing data. Byte transmission protocol T = 0 Case 2 command When a case 2 command shall return more than 256 bytes, only the length Le = 00 shall be authorized by the card, else the card returns RES_REDO_ERR. For Le=0, the card returns 256 bytes and a status RES_MORE + xx where xx represents the remaining data ( xx = 00 if remaining data length 256 bytes). The retrieval sequence is open.

FINEID - S1 / Application Note 1 3(10) The command used to retrieve the remaining data is a Get Response command. For any subsequent Get Response command: If (Le > Licc with Licc < 256), the card returns RES_REDO_ERR + Licc. The retrieval sequence remains open. If Le = Licc and Licc < 256) or (Le=0 and Licc=256) the card returns Licc byte and a status RES_OK. The retrieval sequence is closed. If Le = 00 with Licc > 256, the card returns 256 bytes and the status RES_MORE + xx where xx represents the remaining data ( xx = 00 if remaining data length 256 bytes). The retrieval sequence is open. Case 4 command After the processing of the case 4 command has been completed without error, if outgoing data length > 256 bytes, the card returns RES_MORE. For any subsequent Get Response command the process is the same as for the case 2. 2 Commands supporting command chaining mechanism 2.1 GET DATA GET DATA command is used for retrieving a public key part of a RSA key pair. The file from which the key information is being retrieved must have been selected using the SELECT FILE command. Note: If retrieving the public part of a 2048 RSA key pair, the chaining mechanism must be used. Byte Value CLA 00h or 10h (if chaining mechanism used) INS CAh P1 01h P2 See Table 2 Lc Empty Data Empty Le Number of bytes expected in response Table 1. GET DATA command APDU

FINEID - S1 / Application Note 1 4(10) b8 B7 b6 b5 B4 b3 b2 b1 Hex Coding of the P2 Meaning 0 0 0 0 0 0 0 1 '00' Key info: algorithm identifier, length of modulus and length of public exponent 0 0 0 0 0 0 1 0 '01' Modulus 0 0 0 0 0 0 1 1 '02' Public exponent Any other value - RFU Table 2. Coding of P2 of GET DATA command Data field See Table 4 SW1-SW2 Status bytes GET DATA Response APDU Table 3. GET DATA response APDU GET DATA Response APDU Data field Value of P1 Value of P2 Data field coding 01h 00h Value Length algorithm identifier ( 92 00 (RSA CRT) is the only currently supported value) bit length of modulus 2 bit length of public exponent 2 01h 01h Value Length bit length of modulus 2 Modulus 01h 02h Value Length bit length of public exponent 2 Public exponent Table 4. Response data field of GET DATA command 2 var var

FINEID - S1 / Application Note 1 5(10) 2.2 Applet version To trace the functional applet version a dedicated TAG is added to the Get Data command. In case of the couple P1-P2 parameter equals DF - 30, the applet version is returned on 5 bytes according to the following table: Name Value in ASCII Length in bytes V : 1 byte ASCII coded for version, RR : 2 bytes ASCII coded for release v V. RR 5 Table 5. Applet version Example of version: For an applet 1.25, the ASCII value is: v1.25 and the hexadecimal value is: 76 31 2E 32 35. Success conditions for GET DATA 61xx' RES_MORE xx data to available through Get Response command 9000' RES_OK OK Table 6. GET DATA success conditions Error conditions for GET DATA '6400' RES_EXEC_ERR Execution aborted (RSA file is deactivated) ' 6982 RES_AC_ERR Security status not satisfied 6A81 RES_FUNC_ERR Function not supported (P1-P2 not recognised) '6A88' RES_NO_DATA_ERR Referenced data not found (current file is DF or EF but not RSA key file, or RSA file is empty) 6Cxx RES_REDO_ERR Wrong length (wrong L e field; xx indicates the exact length) Table 7. GET DATA error conditions

FINEID - S1 / Application Note 1 6(10) 2.3 PSO: CDS PERFORM SECURITY OPERATION: COMPUTE DIGITAL SIGNATURE command computes a digital signature. The private key and algorithm to be used must be specified using the MANAGE SECURITY ENVIRONMENT command. The input to the command may be either - a hash code (e.g. SHA-1 hash value 20 bytes), - a DigestInfo ASN.1 structure encapsulating the hash code, or - a full modulus size input buffer (padding done by host application), or - empty (hash code is calculated by preceding PSO: HASH command(s)) according to the selected algorithm reference value. Byte CLA INS P1 P2 Lc Data Le Value 00h or 10h (if chaining mechanism used) 2Ah 9Eh - digital signature data object is returned in response 9Ah data field contains data to be signed Length of subsequent data field or empty If algorithm reference in SE = 00h - Data to be signed (e.g. encapsulated hash code). Padding is done to the full modulus length by the host application. If algorithm reference in SE = 02h: - Hash code encapsulated by the host application into DigestInfo structure. Padding is done internally by the card. If algorithm reference in SE = 12h - Hash code. Card encapsulates the hash into DigestInfo structure and pads it internally according to PKCS#1 v1.5 into full modulus length. Or - None. Hash is computed by preceding PSO: HASH command(s). Empty or maximum length of data expected in response Table 8. PSO: COMPUTE DIGITAL SIGNATURE command APDU Byte Data SW1-SW2 Value Digital signature Status bytes Table 9. PSO: COMPUTE DIGITAL SIGNATURE response APDU

FINEID - S1 / Application Note 1 7(10) Success conditions for PSO: COMPUTE DIGITAL SIGNATURE 61xx' RES_MORE xx data to available through Get Response command 9000' RES_OK OK Table 10. PSO: COMPUTE DIGITAL SIGNATURE success conditions Error conditions for PSO: COMPUTE DIGITAL SIGNATURE 6700 RES_LEN_ERR Wrong length '6982 RES_AC_ERR Security status not satisfied '6984' RES_REF_INVALID_ERR Reference data invalidated (RSA file is deactivated) '6985' RES_COND_ERR Conditions of use not satisfied (SE for operation not set correctly or hash not computed) 6A81 RES_FUNC_ERR Function not supported 6A86 RES_PAR_ERR Incorrect parameters P1-P2 6F00 RES_GEN_ERR No precise diagnosis is given Table 11. PSO: COMPUTE DIGITAL SIGNATURE error conditions 2.4 PSO: DECIPHER PERFORM SECURITY OPERATION: DECIPHER command decrypts an encrypted message (cryptogram). The key and algorithm to be used must be specified using the MANAGE SECURITY ENVIRONMENT command. Note: If deciphering a message with 2048-bit keys, the chaining mechanism must be used. Byte Value CLA 00h or 10h (if chaining mechanism used) INS 2Ah P1 80h decrypted value is returned in response P2 86h - data field contains padding indicator byte (00h according to ISO/IEC 7816-4) followed by the cryptogram (Note! If chaining mechanism is used padding indicator must be included only in the first command in chain) Lc Length of subsequent data field Data 00h (padding indicator byte) cryptogram (Note! If chaining mechanism is used padding indicator must be included only in the first command in chain) Le Empty or maximum length of data expected in response

FINEID - S1 / Application Note 1 8(10) Table 12. PSO: DECIPHER command APDU Byte Data SW1-SW2 Value Decrypted data Status bytes Table 13. PSO: DECIPHER response APDU Success conditions for PSO: DECIPHER 61xx' RES_MORE xx data to available through Get Response command 9000' RES_OK OK Table 14. PSO: DECIPHER success conditions Error conditions for PSO: DECIPHER 6700 RES_LEN_ERR Wrong length '6982 RES_AC_ERR Security status not satisfied '6984' RES_REF_INVALID_ERR Reference data invalidated (RSA file is deactivated) '6985' RES_COND_ERR Conditions of use not satisfied (SE for operation not set correctly or hash not computed) 6A81 RES_FUNC_ERR Function not supported 6A86 RES_PAR_ERR Incorrect parameters P1-P2 6A80 RES_DATA_ERR Incorrect parameters in data field (padding indicator or padding of deciphered data invalid) 6F00 RES_GEN_ERR No precise diagnosis is given Table 15. PSO: DECIPHER error conditions 2.5 PSO: HASH PERFORM SECURITY OPERATION: HASH command computes a hash sum. The algorithm to be used must be specified using the MANAGE SECURITY ENVIRONMENT command (using DST or HT CRDO in the data field). Currently only supported algorithm is SHA-1. This command supports command chaining mechanism, which utilizes the CLA value to indicate the end of the command chain. The command chain has CLA = 10h for all but the last command of the chain, which has CLA = 00h. In chained commands the commands with CLA = 10h shall carry only data quantities which are multiples of the block size of the hashing algorithm (64 bytes for SHA-1). The last command of the chain has no data length limitations. In order to be able to sign or verify the generated hash sum, the CLA must be 00h (end of chain) in the PSO: HASH command given immediately before the PSO: COMPUTE DIGITAL SIGNATURE command.

FINEID - S1 / Application Note 1 9(10) Byte CLA INS P1 P2 Lc Data Le Value 00h or 10h (if chaining mechanism used) 2Ah 90h 80h Length of subsequent data field Data to be hashed Empty or maximum length of data expected in response. Table 16. PSO: HASH command APDU The data field may contain zero or more (plain value) bytes to be integrated into the hash sum (if no bytes are provided, the initial hash state is generated). Length of the data field shall be multiple of the block size of the hashing algorithm (64 bytes for SHA-1) for all but the last command of the chain. For the further processing of the computed hash code the following cases have to be distinguished: 1. The hash code is stored in the card: the calculated hash code is stored in the card and available for use in a subsequent command (PSO: COMPUTE DIGITAL SIGNATURE). In this case the Le field of PSO:HASH command is empty and the algorithm identifier specified in the previous MSE:SET command (using the DST CRDO) shall be 12h. In this case it not possible to read out the generated hash sum. 2. The hash code is delivered by the card in the response. The Le field has to be set to the appropriate length (20 bytes for SHA-1). Byte Data SW1-SW2 Value Empty or calculated hash Empty: the used MSE:SET command before PSO:HASH contains DST CRDO Calculated hash: the used MSE:SET command before PSO:HASH contains HT CRDO Status bytes Table 17. PSO:HASH response APDU 9000' RES_OK OK Success conditions for PSO: HASH Table 18. PSO: HASH success conditions

FINEID - S1 / Application Note 1 10(10) Error conditions for PSO: HASH 6700 RES_LEN_ERR Wrong length '6985' RES_COND_ERR Conditions of use not satisfied (SE for operation not set correctly or hash not computed) 6A81 RES_FUNC_ERR Function not supported 6A86 RES_PAR_ERR Incorrect parameters P1-P2 6A80 RES_DATA_ERR Incorrect parameters in data field (length of DO incorrect) Table 19. PSO: HASH error conditions

Väestörekisterikeskus 2011