EN 419212-2-2017 en Application Interface for Secure Elements for Electronic Identification Authentication and Trusted Services - Part 2 Signature and Seal Services.pdf

1、BSI Standards PublicationWB11885_BSI_StandardCovs_2013_AW.indd 1 15/05/2013 15:06Application Interface for Secure Elements for Electronic Identification, Authentication and Trusted ServicesPart 2: Signature and Seal ServicesBS EN 4192122:2017National forewordThis British Standard is the UK implement

2、ation of EN 4192122:2017. Together with BS EN 419212 parts 1, 3, 4 the value of the KID and the purpose of the signature password shall be indicated in the cryptographic information objects.Also other passwords may be of the type “local”.KID = 0x Key reference to global reference data; the value of

3、the KID and the purpose of the password shall be indicated in the cryptographic information objects.In order to allow the coexistence of EMVapplications and ESIGNapplications on the same ICC, only the three least significant bits should be used to differentiate keys. Refer to 6.5.12.2 Table 23 of 23

4、.Password Based Mechanisms should implement PIN error or usage counters in order to avoid exhaustive retries with the PIN or password.Table 5 VERIFY response APDUResponse ParameterMeaningData field absentSW1SW2 Refer to ISO/IEC 781646.2.3 Passwordbased mechanismsPassword based mechanisms provide an

5、implicit user verification by performing a multi-step authentication protocol, see PACEv2 in Clause 8 “Passwordbased authentication protocols”. In contrast to the application as device authentication protocol the corresponding password is not printed on the card but known by the user only. A reset c

6、ounter is recommended to be assigned to the password. A password change and a reset of the Reset Counter shall be done applying the RESET RETRY COUNTER command, see 6.2.6.6.2.4 Presentation formatsThe data field codes the verification data in one of the following formats.17BS EN 4192122:2017EN 41921

7、2-2:2017 (E)Figure 3 Example of coding 12345 in different presentation formatsFigure 3 demonstrates the coding when the different presentation formats are used. The actual presentation format may be retrieved from information presented in DF.CIA (refer to clause 14) unless implicitly known.National

8、regulations may specify additional security requirements.6.2.5 Retry and Usage countersIn order to avoid exhaustive search (brute force) attacks, the password should be protected by an appropriate retry or usage counter. For a password of 6 numerical digits the retry counter is typically 3 to achiev

9、e a guessing probability of 3/106. For longer or randomly chosen alphanumerical passwords a greater value of the retry counter can be selected with a similar or smaller guessing probability.This depends on the range where the password is selected from, e.g. if the password is a randomly chosen strin

10、g of 32 bytes, then a retry counter may even be not necessary. Passwords protecting the usage of signature keys shall consist, unless otherwise specified, of at least 6 digits or characters.In order to avoid an exhaustive search attack on the password under a known resetting code, the resetting code

11、 should be protected by an appropriate usage counter with a usage counter limit with a low value (typically U = 3 for a resetting code of numerical digits).After successful presentation, the appropriate retry counter is automatically reset to its initial value.For the definition of the counter types

12、 refer to Clause 3.6.2.6 Password ChangeThe CHANGE REFERENCE DATA command for changing the global password may be used under the same access conditions defined for the VERIFY command.The change of DF-specific (local) password can only be performed after selection of the appropriate DF.Execution Flow

13、 1 of 1 Table 6 Password Change command APDUCommand ParameterMeaningCLA according to ISO/IEC 78164INS 24 CHANGE REFERENCE DATA18 BS EN 4192122:2017EN 419212-2:2017 (E)Command ParameterMeaningP1 00 no algorithm specifiedP2 0x | 8x KID of referenced passwordLc field Length of command data fieldData fi

14、eld | For the description of the command refer to ISO/IEC 78164, 11.5.7.The length of the existing Reference Data are known in the ICC, so that neither a delimiter nor padding for filling up fixed formats is necessary. The length of the new password therefore computes Lnew= Lc Lold.Table 7 Password

15、Change response APDUResponse ParameterMeaningData field absentSW1SW2 Refer to ISO/IEC 781646.2.7 Reset of RC and setting a new passwordAfter N (N as specified by application) subsequent false presentations of the password, the password is locked and does not allow further usage of the protected func

16、tions.With the ISO/IEC 78164 command RESET RETRY COUNTER, the cardholder can initiate the reset of the RC to its initial value N. The Resetting Code shall have a minimum length of 6 digits2).It is also possible to define a new password with the RESET RC command.The reset of DF-specific (local) retry

17、 counter can only be performed after selection of the appropriate DF.Table 8 RESET RETRY COUNTER command APDUCommand ParameterMeaningCLA according to ISO/IEC 78164INS 2C RESET RETRY COUNTERP1 00 03P2 0x | 8x KID of referenced passwordLc field Length of command data fieldData field see belowFor the c

18、oding of the RESET RETRY COUNTER command refer to ISO/IEC 78164, 11.5.10.The content of the data field depends on the value of P1. The RESET RETRY COUNTER shall not change the security status, i.e. for using the signature creation key a VERIFY command is still required.P1 = 00 Resetting code followe

19、d without delimitation by new reference dataP1 = 01 Resetting codeP1 = 02 New reference dataP1 = 03 Data field absent2) digit can also be a character as part of a password.19BS EN 4192122:2017EN 419212-2:2017 (E)Table 9 RESET RETRY COUNTER response APDUResponse ParameterMeaningData field absentSW1SW

20、2 See ISO/IEC 78164After successful presentation of the Resetting Code, the retry counter of the referenced password is automatically reset to its initial value (typically N = 3) for a 6 numerical digit password.6.3 Biometric user verification6.3.1 GeneralThe support of a biometric user verification

21、 (on-card matching) is optional. User verification shall always be done with a password. If biometric user verification is available in the IFD and ICC then the biometric user verification can be performed instead of password verification.The following general methods of biometric user verification

22、are available:1. The sensor is offcard, whereas the following cases apply:a. The biometric verification data are sent from the interface device to the ICC and is compared by a match on card mechanism.b. The biometric verification and reference data are transformed by a suitable application specific

23、mechanism as e.g. Fuzzy Vault 39 to password / PIN format. The verification mechanism is then performed as used for passwords / PINs by means of the VERIFY command or a password based mechanism2. The sensor is oncard, so there is no need to transmit the biometric verification data from the interface

24、 device to the ICC.Transforming biometric data to a unique value (b.) has the consequence that the biometric algorithm is performed completely in the offcard application and the ICC only has to perform a user verification by means of direct comparison with yes / no response.The users have the benefi

25、t that they do not have to remember their password because it is linked to their biometrics and usually to an additional randomizer. The security of this mechanism is, however, only as sound as the underlying biometric algorithm i.e. it is in general weaker than a password / PIN Comparison based on

26、random passwords.If biometric user verification is supported and the sensor is off-card, the Finger Minutiae Matcher compliant to ISO/IEC 19794-2 shall be used. The On-Card Biometric Comparison Format identified by the CBEFF format type 0005 shall be applied as encoding format for finger minutiae.Th

27、e ICC shall provide the IFD with information about the supported biometric verification service using a Biometric Information Template (BIT) compliant to ISO/IEC 7816-11 that shall be encoded as presented in Table 15. The BIT shall not contain a data object for minutiae order referenced by tag 82, i

28、.e. the ICC shall not rely on an ordering procedure performed by the IFD.6.3.2 Retrieval of the Biometric Information TemplatePrior to the verification, the SCA may need information about:- AlgID of the matching algorithm and key reference of the biometric reference data;- biometric type (e.g. finge

29、rprint);- biometric type instance (e.g. left pointer finger enrolled);20 BS EN 4192122:2017EN 419212-2:2017 (E)- format owner of the biometric data;- format type of the biometric data; on/offcard sensor.This information may be found in the DF.CIA description (refer to clause 14).Alternatively this i

30、nformation may be provided in the Biometric Information Template (BIT), refer to ISO/IEC 781611. The BIT may be present in the DF.CIA or be retrieved with the GET DATA command.The enrolment process is out of the scope of this standard.Table 10 Retrieve Biometric Information Template(s) command APDU

31、(optional)Command ParameterMeaningCLA according to ISO/IEC 78164INS CA GET DATAP1P2 7F60 Example: Biometric Information TemplateLe field 00For the coding of the command GET DATA refer to ISO/IEC 78164, 11.4.3.Table 11 Retrieve Biometric Information Template(s) response APDU (optional)Response Parame

32、terMeaningData field BIT (Value field of Biometric Information Template(s)SW1SW2 Refer to ISO/IEC 78164For the format of the biometric information template refer to 6.3.3.3 “Biometric Templates”.6.3.3 Performing the biometric user verification6.3.3.1 GeneralTwo situations have to be distinguished: S

33、ensor off-card; Sensor oncard.Secure messaging (see 9.7) is required when executing commands on biometric user verification with Sensor offcard.6.3.3.2 Sensor offcardThe sensor is outside the ICC, i.e. the captured biometric data needs to be sent to the ICC for oncard matching.The IFD retrieves the

34、Biometric Information Template by means of a GET DATA command according to clause 6.3. The corresponding path attribute in the Cryptographic Information Application denotes the DF that shall be selected prior to this GET DATA command.Then the IFD uses a VERIFY command to process the biometric data s

35、tructured according to the biometric template.21BS EN 4192122:2017EN 419212-2:2017 (E)Table 12 Biometric user verification command APDU (Biometric verification)Command ParameterMeaningCLA according to ISO/IEC 78164INS 21 VERIFYP1 00P2 xx reference data qualifier according to 6.1.1.Lc field Length of

36、 command data fieldData field refer to Table 14For the structure and content of the APDU refer to ISO/IEC 78164, 11.5.6.Table 13 Biometric user verification 2 of 2- response APDUResponse ParameterMeaningData field absentSW1SW2 Refer to ISO/IEC 781646.3.3.3 Biometric TemplatesTable 14 Biometric data

37、templateTag Length Value7F 2E Var.Biometric Data TemplateTag Length 81 Var. Biometric data with standardized format (primitive encoding)Table 15 Biometric Information TemplateTag Length Value Presence7F 60 Var.Biometric Information Template (BIT) Tag Length Value 83 01 Reference data qualifier accor

38、ding to 6.1.1. MandatoryA1 Var.Biometric Header Template (BHT) in compliance with CBEFF MandatoryTag Length Value 81 01 08 (fingerprint) Mandatory82 01Biometric subtype (refer to ISO/IEC 7816-11:2004, Table C.3)Mandatory87 02 0101 (ISO/IEC JTC 1/SC37) Mandatory88 02 00 05 MandatoryB1 Var.Biometric m

39、atching algorithm parameters OptionalTag Length Value 81 02Minimum number of minutiae required (1 byte, binary coding) | Maximum number of minutiae accepted (1 byte, binary coding)6.3.3.4 Sensor oncardFor the on-card verification, the VERIFY command selects the biometric data reference through P2.22

40、 BS EN 4192122:2017EN 419212-2:2017 (E)Execution Flow Table 16 Biometric verification command APDUCommand ParameterMeaningCLA according to ISO/IEC 78164INS 21 VERIFYP1 00 no algorithm specifiedP2 0x | 8x reference data qualifier acc. to 6.1.1.Lc field Length of command data fieldData field 5F2E 00 |

41、 4D 00 empty verification DO and extended. header list DOFor the description of the command refer to ISO/IEC 78164, 11.5.6.The length of the existing reference data are known in the ICC, so that neither a delimiter, nor padding for filling up fixed formats is necessary.Table 17 Biometric verificatio

42、n response APDUResponse ParameterMeaningData field absentSW1SW2 Refer to ISO/IEC 7816-4 2For the structure and content of the APDU refer to ISO/IEC 78164, 11.5.6.6.3.4 Reset of RCFor resetting the RC, see 6.1.5.With respect to biometric reference data only the RESET RETRY COUNTER command variants th

43、at make use of P1 = 01 and P1 = 03 are specified in this document. The usage of the command variants with P1 = 00 and P1 = 02 is outside the scope of the document as the enrolment process is not defined in this document.7 Digital Signature Service7.1 GeneralThis chapter is related to technical aspec

44、ts of electronic signatures according section 3 “Electronic signature” of the EU Regulation 1.NOTE For QES additional organizational aspects need to be considered like evaluation, certification, CA accreditation.The technical requirements are fulfilled by the specifications of this standard.7.2 Sign

45、ature generation algorithmsFor signature generation, algorithms as referenced in the current European and national algorithm catalogues shall be applied. Examples of existing documents are given in 4 5 6 7.23BS EN 4192122:2017EN 419212-2:2017 (E)7.3 Activation of digital signature serviceIn order to

46、 enable the digital signature service a user verification shall be applied prior to signature generation.NOTE The loop is controlled by the signer, i.e. no signature is created without a willful act.Figure 4 User Verification of the SignerRefer to Figure 1 for the overview of the signature generatio

47、n flow.A knowledge based interaction always expresses the explicit will of the card holder to sign a document whereas a biometric identification does not necessarily imply the intention to sign.For the description of the user verification see clause 6.7.4 General aspectsA digital signature process c

48、onsists of several steps. Some of them are done outside the ICC, some of them are done inside the ICC, and some could be done on either side.Figure 5 Data-Flow chart for signature generation process (RSA Example)24 BS EN 4192122:2017EN 419212-2:2017 (E)Figure 5 shows an example of the alternatives t

49、o process a hash data signing. Signature input formatting aspects are not covered by Figure 5. The numbers 15 refer to the steps described below. The intermediate hashcode is the digest of preceding hash rounds followed by the big endian bit count. Only fully hashed blocks are transmitted, therefore the length of data_1 (on partial hashing) is