Enhanced PKI authentication with trusted product at claimant

Enhanced PKI authentication with trusted product at claimant Enhanced PKI authentication with trusted product at claimant Asahiko Yamada a,*, Tatsuro Ikeda b a National Institute of Advanced Industria[.]

ARTICLE IN PRESS computers & security ■■ (2017) ■■–■■ Available online at www.sciencedirect.com ScienceDirect j o u r n a l h o m e p a g e : w w w e l s e v i e r c o m / l o c a t e / c o s e Enhanced PKI authentication with trusted product at claimant Asahiko Yamada a,*, Tatsuro Ikeda b a b National Institute of Advanced Industrial Science and Technology, 2-3-26 Aomi, Koto-ku, Tokyo 135-0064, Japan Toshiba Corporation, 72-34, Horikawa-cho, Saiwai-ku, Kawasaki 212-8585, Japan A R T I C L E I N F O A B S T R A C T Article history: In this paper, a data structure to enhance PKI (Public Key Infrastructure) authentication is Available online proposed generalizing the concept of ISO/IEC 24761 Current technologies not provide sufficient information on products which are used in the authentication process at the Claim- Keywords: ant to the Verifier As a result, the Verifier cannot sufficiently distinguish the authentication Authentication result executed with a trusted product from that without a trusted product The difference Biometric is made clear if evidence data of the execution of authentication process at the Claimant CMS are generated by the trusted product and used for verification by the Verifier Data struc- Digital signature ture for such data is proposed in this paper as client Authentication Context (cAC) instance IC card Relation to other works and extension of the proposal where biometrics is used are also PKI described for further improvement of PKI authentication For this proposal to realize, stan- Tamper-resilient software dardization activities are to be considered as the next steps Tamper-resistant hardware Trusted device © 2017 The Authors Published by Elsevier Ltd This is an open access article under the CC BY-NC-ND license (http://creativecommons.org/licenses/by-nc-nd/4.0/) Introduction In networked IT environments, remote authentication is essential Remote authentication is one of the most important elements of the security of innumerous applications of governmental, commercial, academic systems and so forth and is applied to such systems Although policy-based authorization makes the Relying Party (RP) possible to change the service level reflecting the level of assurance of the identity, the level of trust of the environment of the Claimant where the authentication protocol is executed is not taken into account appropriately and sufficiently This paper proposes a mechanism with which the Verifier can know the level of trust in the authentication process executed at the Claimant of PKI authentication under the condition that a trusted product with the digital signature generation function such as a tamper- resistant IC card is used for PKI authentication at the Claimant There are two cases for the activation of the private key, with passphrase or biometrics Both cases are discussed in this paper, extending the former to the latter There is also a case in which the private key is generated every time when a biometric characteristic is provided This case is also discussed later in this paper Current technologies Progresses in authentication technologies have been significant in the last decade Single Sign-On (SSO) technologies such as Security Assertion Markup Language (SAML, OASIS, 2005) and OpenID Connect (Sakimura et al., 2014) have made general service providers free from authentication itself and only * Corresponding author E-mail address: yamada.asahiko@aist.go.jp (A Yamada) http://dx.doi.org/10.1016/j.cose.2017.01.001 0167-4048/© 2017 The Authors Published by Elsevier Ltd This is an open access article under the CC BY-NC-ND license (http:// creativecommons.org/licenses/by-nc-nd/4.0/) Please cite this article in press as: Asahiko Yamada, Tatsuro Ikeda, Enhanced PKI authentication with trusted product at claimant, computers & security (2017), doi: 10.1016/ j.cose.2017.01.001 ARTICLE IN PRESS computers & security ■■ (2017) ■■–■■ consume the assertion generated by the Verifier, which is called Identity Provider (IdP) in SAML and OpenID Provider (OP) in OpenID While the technologies in subsequent authentication between the Verifier and the RP, the consumer of the assertion, have been progressed, the technologies in initial authentication between the Claimant and the Verifier have been stable In Web systems, Transport Layer Security (TLS) protocol including its predecessor Secure Sockets Layer (SSL) has been dominant for about twenty years and is still the most major and standard technology The variation of tokens has not changed, something you know, something you have, and something you are In SAML, authentication context is optionally used in assertions to give additional information for the RP in determining the authenticity and confidence of assertions Authentication context contains information how the user is authenticated at the Claimant Although the IdP generates an authentication context at the initial authentication, the IdP does not always have sufficiently trustable information about the authentication process at the Claimant in order to generate an authentication context, considering that the execution environment of the Claimant is not always so sufficiently trustable to the IdP as that of the IdP to the RP For example, the IdP does not have sufficient information to judge whether a tamper-resistant IC card with digital signature function is used at the Claimant or not It is true that a private key stored in a tamper-resistant IC card can be distinguished with the Qualified Certificate specified in RFC 3739 (Santesson et al., 2004) with the Qualified Certificate statement 5.2.4 in ETSI TS 101 862 (ETSI, 2004) which is for secure signature-creation devices with the conditions in Annex III of Directive 1999/93/EC of the European Parliament and of the Council of 13 December 1999 on a Community framework for electronic signatures (European Union, 2000) But the purpose of X.509 certificate itself is to describe the attributes of a user and his/her public key So the use of the extension of X.509 certificate in such a way does not match its original purpose Guidelines and requirements on authentication have been also studied well One of the most important results in this area is NIST SP 800-63-2 Electronic Authentication Guideline (National Institute of Standards and Technology, 2013) It assigns requirements on tokens, token and credential management, authentication process, and assertions to each Level of Assurance (LoA) from Level to Level each of which was introduced in OMB M-04-04 (Office of Management and Budget, 2003) Although SP 800-63-2 requires Level to use Multi-Factor (MF) hardware cryptographic token such as tamper-resistant cryptographic IC card, any of the current authentication protocols does not show sufficient evidence that such a token is used at the Claimant At Level 4, such a protocol may be unnecessary because only in-person registration is allowed at Level and it can be assured that such a token is issued and used in authentication process at the Claimant But in Level and Level to which remote registration is allowed, it is not evident for the Registration Authority (RA) or the Credential Service Provider (CSP) whether a public key pair is generated and stored in a tamper-resistant IC card in registration process, and it is not evident either to the Verifier whether such a product is used in authentication process, for example In Level and Level 3, it would be desirable for the RP to know more information about the trust level of the authentication process executed at the Claimant Then the RP can provide its services according to the level of trust In the area of biometric authentication, a similar motivation and a solution can be found in ISO/IEC 24761 Authentication Context for Biometrics (ACBio) (ISO/IEC 24761, 2009, ISO/IEC 24761, 2013) The work in this paper is a generalization of the idea in ISO/IEC 24761 In the following, terms and definitions in SP 800-63-2 are basically applied unless otherwise specified ISO/IEC 24761, a related work in biometric authentication ISO/IEC 24761 referred as ACBio is an enhancement for biometric authentication while this proposal is that for PKI authentication ACBio is a solution to the technological issues of biometric authentication used in the Internet environment The issues are listed in the threat analysis done in a paper (Ratha et al., 1999) and they are categorized into three categories The first is that subprocesses may be replaced with malware Here a subprocess is an execution component in biometric authentication, namely data capture to sense human body to output raw biometric sample, intermediate signal processing to process raw biometric sample to intermediate processed biometric sample, final signal processing to process intermediate biometric sample to processed biometric sample, storage to store and retrieve enrolled biometric reference template, biometric comparison to compare and calculate the score of similarity of processed biometric sample to biometric reference template, or decision to decide match or non-match from the score (see Fig 1) The second is that the enrolled biometric reference template may be replaced with that of another person such as an attacker The last is that the data transmitted between subprocesses may be replaced with another data A paper (Hachez et al., 2000) has given a solution to the issues as general as possible for the case where smart cards are used Another paper (Bechelli et al., 2002) has also given a solution for a specific type of smart card for biometric authentication, called Match on Card in the paper but currently called on-card biometric comparison in general, with the assumption that the smart card is ISO/IEC 7816 conformant These papers realize secure biometric authentication But if the biometric authentication is executed at the client environment, the Verifier of biometric authentication via the Internet still cannot know whether it can trust the result of biometric authentication ACBio has solved these issues by generation and verification of evidence data of the executed biometric processing under the assumption that trusted biometric products are used Authentication using the specification of ACBio is called ACBio authentication A trusted biometric product is called a Biometric Processing Unit (BPU) in ACBio In production process, a manufacturer of a BPU (BPU manufacturer) has to generate a BPU report to the BPU product in ACBio authentication where it is assumed that the BPU manufacturer generates its key pair and gets the X.509 certificate in advance In the BPU report which is data of type SignedData (Housley, 2004; Hoffman and Schaad, 2010) digitally signed with Please cite this article in press as: Asahiko Yamada, Tatsuro Ikeda, Enhanced PKI authentication with trusted product at claimant, computers & security (2017), doi: 10.1016/ j.cose.2017.01.001 ARTICLE IN PRESS computers & security ■■ (2017) ■■–■■ data capture raw biometric sample intermediate biometric final intermediate sample signal signal processing processing processed biometric sample comparison score decision comparison comparison decision processed biometric reference storage Fig – Subprocesses and data flows in biometric authentication the private key of the BPU manufacturer, information about the BPU such as the modality which the BPU processes, the subprocesses implemented and the data flow in the BPU is contained In ACBio authentication, a key pair for the BPU is generated and the X.509 certificate for the public key of the BPU is issued They are stored in the BPU with the BPU report at production process At registration process, Biometric Reference Template (BRT) certificate is issued to BRT by a BRT certificate authority in ACBio authentication The BRT certificate is a digitally signed data of type SignedData by a BRT certificate authority and links a BRT to a user For privacy reasons, the BRT certificate does not contain the BRT itself but contains the hash value of the BRT There is evidence data named ACBio instance for enrolment, which is digitally signed with the private key of the BPU, to show the generation and storage of the BRT is securely done in the BPU In ACBio authentication, each BPU used in the enrolment generates its ACBio instance for enrolment The ACBio instances for enrolment show the BPUs used in the enrolment and the integrity of the data transmitted between the BPUs if the enrolment is done with multiple BPUs The ACBio instances for enrolment are optionally set in the BRT certificate From the ACBio instances for enrolment, the BPU where the BRT is stored is also identified ACBio instances for enrolment may be used to check whether the enrolment satisfies the security requirement by the BRT certificate authority to issue the BRT certificate, and also by the Verifier later in authentication process, depending on the security policies of the BRT certificate authority and the Verifier respectively At authentication process, ACBio authentication assumes challenge response mechanism to prevent replay attacks An ACBio instance is generated in each BPU which takes part in biometric authentication process Fig overviews the data structure of ACBio instance An ACBio instance contains the BPU report This gives information to the Verifier about the product which executes authentication protocol at the Claimant It also contains the challenge which is called Control Value in ACBio, the Biometric Process Block, and the BRT certificate, which is contained only if the BPU stores the BRT In addition to all the data mentioned above, the ACBio instance contains the digital signature to them with the private key of the BPU used ACBio instance gives the evidence of the successful execution of the authentication protocol done in the BPU at the Claimant and solves the technological issues written at the be- ginning of Section With the BPU report and the digital signature of the ACBio instance, the Verifier can know that the part of processing in biometric authentication has been executed in the BPU In the BPU report, there is a field for security report for future use but there is no organization that issues such report yet Therefore there has to be an assumption that the Verifier knows about the security of the BPU in advance at present With the BRT certificate and the digital signature of the ACBio instance, the Verifier can know that the BRT stored in the enrolment process is used in the biometric authentication With the Biometric Process Blocks in the ACBio instances, the Verifier can check the integrity of the transmission of the data between BPUs as follows Suppose that there is a data transmission from BPU1 to BPU2 as in Fig In ACBio authentication, every BPU shall generate its own ACBio instance which contains the hash information of the input/output data to/from the BPU in Biometric Process Block as depicted in Fig Hash value in the left ACBio instance of BPU1 is the hash value of the output from BPU1 while Hash value in the right is that of the input to BPU2 The Verifier can conclude that the integrity of the transmission is kept ACBio instance BPU report Information about BPU X.509 certificate of BPU manufacturer Signature value Challenge Biometric Process Block (Information about the data transmitted between BPUs ) BRT certificate (present only if BPU contains BRT) Information about BRT ACBio instance for enrolment (optional) X.509 certificate of BRT certificate authority Signature value X.509 certificate of BPU Signature value Fig – Simplified data structure of ACBio instance Please cite this article in press as: Asahiko Yamada, Tatsuro Ikeda, Enhanced PKI authentication with trusted product at claimant, computers & security (2017), doi: 10.1016/ j.cose.2017.01.001 ARTICLE IN PRESS computers & security ■■ (2017) ■■–■■ BPU1 BPU2 ACBio instance generated by BPU1 ACBio instance generated by BPU2 Biometric Process Block Biometric Process Block Information on output from BPU Information on input to BPU Hash information Algorithm identifier Hash information Algorithm identifier Hash value Hash value Fig – Outline of the mechanism on Biometric Process Block if the pair of Algorithm identifier and Hash value in the left ACBio instance is the same as that in the right ACBio instance because these two pairs are generated by independent BPUs Here the hash algorithm shall be negotiated among the Verifier and BPUs in advance The idea of ACBio enhances biometric authentication used in the Internet but the name ACBio (Authentication Context for Biometrics) is inappropriate As written in Section 2, authentication context in SAML is information in assertions, i.e., information sent from the Verifier to the RP while ACBio instance is not but is sent from the Claimant to the Verifier In this context, the name cAC (client Authentication Context) is introduced and used in this paper Problem definition In an environment where a trusted product is not used at the Claimant for PKI authentication protocol, there may be possibilities that the private key is compromised, i.e., an attacker may get and misuse it for spoofing When a trusted product is used, it will be assured that the private key is not stolen under certain conditions, as assumptions listed in Section There should be an authentication protocol for the Verifier to distinguish the above two cases Assumptions (C) The private key embedded in production process or generated in the trusted product cannot be exported (D) The trusted product has a function to manage the couples of private key and X.509 certificate of the public key (E) The trusted product can digitally sign only with a private key embedded in production process or one generated in the trusted product (F) The trusted product has functions proposed in this paper for authentication process In addition to the above assumptions to the trusted products, assume also that the whole production process of trusted products is trusted Therefore the private key embedded to the trusted product is never leaked in the production process The assumptions (A) and (D) are necessary to generate data of type SignedData in a product If a trusted product can digitally sign with an imported private key, then the private key may have been already compromised before it is imported Therefore the assumption (E) is necessary to assure that the digital signature is generated by the trusted product To assume (E), the private key has to be generated in production process or it has to be generated in the trusted product after production process Therefore the assumption (B) is necessary Without (C) the private key may be misused These assumptions are appropriate since tamper-resistant PKI cards conformant to ISO/IEC 7816-4 (ISO/IEC 7816-4, 2013) and (ISO/IEC 7816-8, 2004) satisfy (A) to (E) The implementation of (F) is not difficult as is to be seen later In the following, the detailed communication protocol including negotiation is not discussed In this paper, assume that the trusted products considered have the following assumptions (A) The trusted product has digital signing function (B) The trusted product has generation function of public key pairs Proposal In this paper, a data structure named client Authentication Context (cAC) is proposed to enhance the PKI authentication pro- Please cite this article in press as: Asahiko Yamada, Tatsuro Ikeda, Enhanced PKI authentication with trusted product at claimant, computers & security (2017), doi: 10.1016/ j.cose.2017.01.001 ARTICLE IN PRESS computers & security ■■ (2017) ■■–■■ tocol under the condition that a trusted product with assumptions from (A) to (F) is used at the Claimant Hereafter a trusted product with the assumptions is called a cAC product and authentication using cAC is called cAC authentication The cAC authentication enables the Verifier to judge whether a cAC product is used for the authentication process In short, this is done with a combination of product authentication and user authentication techniques, PKI based user authentication assured by PKI based product authentication Authentication protocol for cAC authentication is also discussed.The problem cannot be solved only with the authentication protocol but with a series of processes beginning from the production process as in ACBio.This proposal tries to give a solution to the problem as universal as possible There are three categories of cAC products from the view point how the user’s private key becomes available The first category is that it is activated by a passphrase The second is that it is activated with biometric authentication The third is that it is generated by biometric data captured at a biometric sensor device (Takahashi et al., 2015) Here only the first case is discussed The latter cases will be discussed later There is another categorization of product implementations into a category of software and one of hardware The former is tamper-resilient software while the latter is tamper resistant hardware These two categories are considered in this paper though there would be finer categorizations on product implementations 6.1 Production process In the production process of cAC products, the cAC product manufacturer needs several procedures for cAC authentication afterwards The cAC product manufacturer has to generate its public key pair and get the X.509 certificate issued in advance The private key is used to digitally sign cAC product report which gives information about the cAC product Digitally signed with the private key of the cAC product manufacturer, cAC product report becomes trusted data if there is an assumption that the Verifier trusts the cAC product manufacturer Hereafter certificateMnf denotes the X.509 certificate of the public key of the cAC product manufacturer In the following, type means ASN.1 type For generation of cAC product report, a type SignedData, specified in RFC 3852 (Housley, 2004)/RFC 5911 (Hoffman and Schaad, 2010) Cryptographic Message Syntax (CMS), is applied In SignedData, the signed object is the field encapContentInfo of type EncapsulatedContentInfo which consists of two fields The first is a field to indicate the data type of the data which is DER encoded in the second field To indicate the data type, OBJECT IDENTIFIER type is used The second is the content itself carried as an octet string whose data type is identified with the first field The type identifier for the content of cAC product report is defined as id-content-cPR-pssphrs of type OBJECT IDENTIFIER The corresponding content type ContentCPRPssphrs identified by id-content-cPR-pssphrs is defined to have four fields The first field productType gives information that the product is a tamper-resilient software or tamper-resistant hardware product The second field levelCMVP is to show the level of Cryptographic Module Validation Program specified in FIPS 140-2 (National Institute of Standards and Technology, 2001) and ISO/IEC 19790 (ISO/IEC 19790, 2012) if the cryptographic module in the cAC product is certified The third reqLengthPssPhrs and fourth minLength are a field to show whether there is a requirement for the length of passphrase, and a field for the required minimal length of passphrase if there is With the above information, the Verifier knows the extent to which it can trust the cAC product In ASN.1 notation, ContentCPRPssphrs is specified as follows: Let SIGNEDDATA(eCTypeID, ContentType) denote a type which is derived from SignedData where the field eContentType in encapContentInfo is specified to take eCTypeID and eContent in encapContentInfo is OCTET STRING of the DER encoding of data of type ContentType Then a type CACProductReport for cAC product report is defined as SIGENDDATA(id-content-cPR-pssphrs, ContentCPRPssphrs) Data of this type shall be digitally signed with the private key of a cAC product manufacturer Therefore certificateMnf is set in one of certificates in the cAC product report At the last of production process of cAC product, a public key pair shall be generated and the X.509 certificate for the public key, which is denoted by certificatePrd hereafter, shall be issued In the X.509 certificate, the field subject of type Name in the field tbsCertificate of type TBSCertificate shall contain the name of the cAC product and that of the cAC product manufacturer The name of the cAC product manufacturer in the field subject shall be the same as that in the field subject in the X.509 certificate of the cAC product manufacturer in the cAC product report The private key and the X.509 certificate shall be stored in the cAC product together with the already generated cAC product report 6.2 Registration process To become a Claimant in PKI authentication process, a user has to generate the public key pair and get an X.509 certificate of the public key It is also the same in cAC authentication, but the Claimant has to generate the key pair in the cAC product Otherwise, if the public key pair is generated outside the cAC product, the imported key pair cannot generate digital signature because of assumption (E) There are no corresponding data in cAC authentication to the ACBio instance for enrolment There seems to have to be “key generating context” in cAC authentication But it is Please cite this article in press as: Asahiko Yamada, Tatsuro Ikeda, Enhanced PKI authentication with trusted product at claimant, computers & security (2017), doi: 10.1016/ j.cose.2017.01.001 ARTICLE IN PRESS computers & security ■■ (2017) ■■–■■ cAC instance cAC product report Data of type ContentCPRPassphrase X.509 certificate of cAC product manufacturer Signature value CSBU Challenge X.509 certificate of user Signature value X.509 certificate of cAC product Signature value Fig – Overview of data structure of cAC instance redundant because the private key used in authentication process is assured to have been generated in the same cAC product in registration process by assumptions (B) and (E) Furthermore it is assured that the digital signature is generated in the cAC product by assumption (C) and (E) 6.3 Authentication process In the cAC product, the pair of the private key and X.509 certificate for the cAC product, the pair of the private key and X.509 certificate for the user, and the cAC product report are stored before the authentication process starts With these data, a cAC instance, an evidence data of the cAC authentication process at the Claimant, is defined In this paper, challenge response mechanism is assumed to be applied in the authentication protocol in order to prevent replay attacks This assumption is appropriate since the protocols used in PKI authentication generally apply challenge response mechanism But before defining the authentication protocol, the data structure is defined A type ChallengeSignedByUser is defined as SIGNEDDATA(id-data, OCTET STRING) When the Claimant receives a challenge from the Verifier, data of type ChallengeSignedByUser is generated at the Claimant setting the challenge of type OCTET STRING into eContent and digitally signing the challenge with the user’s private key which is activated with a passphrase input by the user Hereafter data of type ChallengeSignedByUser is called a CSBU A type ContentClientAC identified by the type identifier idcontentClientAC is defined as: Then a type ClientACInstance is defined as: SIGNEDDATA(id-contentClientAC, ContentClientAC) To generate a cAC instance of type ClientACInstance, the cAC product report and the data of ChallengeSignedByUser generated as in the above are used For digital signing, the private key of the cAC product is used Therefore the X.509 certificate set in certificates in the cAC instance is certificatePrd Fig shows a simplified data structure of cAC instance where shaded boxes indicate data imported from RFC 3852 At the Verifier, a cAC instance is verified as follows: The Verifier checks the cAC product report This consists of signature verification, checking of the product type, the level of cryptographic function, and the passphrase policy implemented on the cAC product By checking the cAC product report, the Verifier can know whether the cAC product satisfies the authentication policy of the RP for example, and that the cAC product is manufactured by the cAC product manufacturer with the X.509 certificate in the cAC product report The Verifier checks the CSBU The Verifier can know whether there was a replay attack by checking the challenge in the CSBU, and whether the user generated the digital signature The digital signature of the challenge is verified with the public key in the X.509 certificate in the CSBU The Verifier verifies the digital signature of the cAC instance With this verification, the Verifier can conclude that the Claimant has done the authentication process in the cAC product because the digital signature has been calculated with the private key of the cAC product which has been stored in the cAC product since key generation because of assumptions from (A) to (E) This solves the problem stated in Section Fig summarizes all the operations in all the processes that are proposed in this paper In the region of processing in cAC product in Fig 5, surrounded by the dotted line, the relations of “contained” and “digitally sign” are assured by the assumption from (A) to (F) These make the evidence of the execution of authentication process in cAC product trusted Considerations 7.1 Comparison with the qualified certificate model The Qualified Certificate can be used to show that the private key paired to the public key to which the certificate is issued is stored and used in a trusted product If a vulnerability of the trusted product concerning the storage of the private key is found, then all the Qualified Certificates to the users who use the trusted product to digitally sign with have to be revoked while only one cAC product report of the trusted product has to be invalidated in the proposed model There is a big difference in efficiency of the validation process at the Verifier In order to revoke the Qualified Certificates, the CA has to store each of the information about the trusted product corresponding to each of the Qualified Certificates issued The Qualified Certificate does not show which trusted product the private key is stored and used in As a result, the Verifier can know nothing about the trusted product used in the authentication process and can give less information about the authentication process to the RP than in the proposed model This information to the RP is important for policybased authorization Therefore the proposed model is more Please cite this article in press as: Asahiko Yamada, Tatsuro Ikeda, Enhanced PKI authentication with trusted product at claimant, computers & security (2017), doi: 10.1016/ j.cose.2017.01.001 ARTICLE IN PRESS computers & security ■■ (2017) ■■–■■ Fig – Trust relation in cAC authentication appropriate for the policy-based authorization than the Qualified Certificate model 7.2 Application of the proposal to private key activation by biometrics In ITU-T SG 17 and ISO/IEC JTC 1/SC 27, a project to make a common text on Biometric Hardware Security Module (BHSM) is going on It is at Equity (Draft International Standard) stage in SC 27 at the time of writing this paper A typical example of BHSM is a PKI card in which the private key is activated by biometric authentication To show that a BHSM is used in the authentication process, cAC can be applied with modification There are two possibilities in the modification depending on the security policy on authentication and also on the implementation of biometric authentication in relation to the cAC product The relation between the implementation of biometric authentication and the cAC product is classified into three types from the view point of this paper The first type is biometric authentication inclusive to cAC product In this type, the whole biometric authentication subprocesses are implemented in the cAC product ((a) in Fig 6) The second type is biometric authentication non-inclusive to cAC product in which some parts including the decision subprocess but not the whole of biometric authentication subprocesses are implemented outside of the cAC product The last type is biometric authentication exclusive to cAC product in the whole biometric subprocesses are implemented outside of the cAC product Fig depicts the three types where (b) is a typical example of noninclusive type There is a case where the cAC product implements only the storage subprocess This case is classified as type (c) (see the dotted area in Fig 6), not type (b), in this paper Here the biometric authentication is used for private key activation Therefore the important issue is how the result of the biometric authentication is input to the cAC product When the cAC product is used only to store the biometric template, it outputs the biometric template and receives the result after the biometric authentication is done outside It is the same as (c) in that the cAC product received the result of biometric authentication from the outside of the cAC product In the first type (a), the whole processing of biometric authentication is trusted because it is executed in a trusted environment of the cAC product The result of biometric authentication is also sent and received inside the cAC product to activate the private key This is the most secure way of implementation In the case of smart card, it is a System on Card (SoC) of biometric authentication as well as a PKI card As far as the authors know, there is only one implementation of SoC product, which is for fingerprint (see http://morix-ic.com/en/) But the authors not know whether it also has a digital signature mechanism This shows that the type (a) is ideal from the view point of security but is not easy to realize from the view point of cost and technology In the second type (b), some parts of processing of biometric authentication are executed outside of the cAC product The processing outside of the cAC product is not trusted in general, as seen in Section The type (b) is not perfect from the view point of security but is a realistic model There are examples of on-card biometric comparison, which has three subprocess functions depicted (b) in Fig To use a system of type (b) securely in an open environment, it should be shown to the Verifier whether the biometric processing outside of the cAC product is trusted In the third type (c), the whole processing of biometric authentication is executed outside of the cAC product It is easy Please cite this article in press as: Asahiko Yamada, Tatsuro Ikeda, Enhanced PKI authentication with trusted product at claimant, computers & security (2017), doi: 10.1016/ j.cose.2017.01.001 ARTICLE IN PRESS computers & security ■■ (2017) ■■–■■ (a) cAC product (b) cAC product (c) cAC product Fig – Types of relation between biometric authentication and cAC product to build a system of type (c), combining a biometric system with a cAC product But the whole security issues that (Ratha et al., 1999) pointed out, already referenced in Section 3, apply For the Verifier to trust the result of PKI authentication, it should be also shown whether the whole biometric processing is securely executed As described in Section 3, an ACBio instance specified in ISO/ IEC 24761 gives evidence information of biometric processing executed in a product In the first type where the implementation of biometric authentication is inclusive to cAC product, the use of ISO/IEC 24761 is not necessary because the execution is trusted, as stated above, though the use may depend on the security policy on authentication of the RP In the second type where the implementation of biometric authentication is non-inclusive to cAC product, the use of ISO/IEC 24761 is recommended to the product which takes part in biometric authentication to show the execution is trusted or not It is also recommended for the cAC product to show the integrity of the data flow from the outside of the cAC product For the third type, there is no biometric processing in the cAC product but outside of the cAC product the use of ISO/IEC 24761 is recommended Table summarizes these considerations The data type ContentCPRPssphrs in CACProductReport has to be replaced with another data type because the private key is activated by biometric authentication, not by passphrase The data type should contain information on the modality used for biometric authentication because it may be included in the security policy on authentication of the RP Type ContentCPRBiometicsSimple, which replaces ContentCPRPssphrs, is defined as follows: Type UseBiometrics shows how biometrics is used for the cAC product In this case, the value keyActivation shall be taken The value keyGeneration shall be taken when biometrics is used for private key generation which is discussed later in Section 7.3 BiometricType and BiometricSubtype are types for modalities defined in ISO/IEC 19785-3 (ISO/IEC 19785-3, 2007) The type is used for the type of implementation of biometric authentication inclusive to cAC product but also may be used Table – Recommendation of use of ISO/IEC 24761 to biometric products used for activation of private key of cAC product Type of biometric authentication in relation to cAC product Inclusive to cAC product Non-inclusive to cAC product Exclusive to cAC product Use of ISO/IEC 24761 cAC product Outside of cAC product Optional Recommended – – Recommended Recommended Please cite this article in press as: Asahiko Yamada, Tatsuro Ikeda, Enhanced PKI authentication with trusted product at claimant, computers & security (2017), doi: 10.1016/ j.cose.2017.01.001 ARTICLE IN PRESS computers & security ■■ (2017) ■■–■■ for the type non-inclusive and the type exclusive to cAC product depending on the security policy on authentication of the RP For the type of implementation of biometric authentication non-inclusive to cAC product, ACBio instance(s) should be generated by product(s) other than the cAC product If the Verifier needs to validate the biometric processing executed in the cAC product through the authentication protocol, generation of an ACBio instance is recommended as written in Table but it is redundant to use ACBio instance as is defined To deal with this issue, ContentCPRBiometicsDetail shall be defined as follows to replace ContentCPRBiometicsSimple: extended cAC instance /extended ACBio instance extended cAC product report/extended BPU report Data of type ContentCPRBiometicsDetail X.509 certificate of cAC product/BPU manufacturer Signature value CSBU (as in Fig.4) Biometric Process Block BRT certificate (optional) X.509 certificate of cAC product/BPU Signature value Fig – Overview of data structure of extended cAC instance Here again keyActivation shall be taken for the field useBiometrics BPUFunctionReport and BPUSecurityReport are types defined in ISO/IEC 24761 to show the specification of function and security of BPU In this case, a cAC product is also considered as a BPU from the view point of ISO/IEC 24761 A cAC product report with ContentCPRBiometicsDetail is regarded as an extension of BPU report with three fields, productType, levelCMVP and useBiometrics, added to the data structure of BPUReportContentInformation in a BPU report In registration process, X.509 certificate and BRT certificate shall be issued The issuance of these two types of certificate may be done at different TTPs In ISO/IEC 24761, harmonization with PKI authentication has been considered When both PKI and biometrics are used, the X.509 certificate shall be issued before the BRT certificate is issued From a BRT certificate, the corresponding X.509 can be referred to with the field pkiCertificateInformation of type PKICertificateInformation in the BRT certificate This correlates PKI authentication and biometric authentication in ISO/IEC 24761 In authentication process, extended cAC instance whose data structure is depicted in Fig shall be used The extended cAC instance can be also regarded as extended ACBio instance If it is regarded as extended ACBio instance, the BPU report and the control value are considered to be replaced with the above defined cAC product report and CSBU respectively With this extended cAC instance (or extended ACBio instance), cAC authentication and ACBio authentication are unified 7.3 Application of the proposal to signature scheme with a fuzzy private key In signature scheme with a fuzzy private key (Takahashi et al., 2015), a private key, also the corresponding public key, is generated from the processed biometric sample In this scheme, the biometric template is not used Therefore no discussing is necessary on biometric template protection which is one of the most difficult technological issues in biometric systems This is the biggest advantage of this scheme compared with the other biometric authentication technologies The relation between the implementation of biometric processing and the cAC product is classified into three types, inclusive, non-inclusive, and exclusive, from the view point of this paper, as depicted in Fig The three types are similar to those defined in Section 7.2 Here again (b) in Fig is just a typical example of the non-inclusive type The discussions on the security and difficulties/easiness of implementation of the system to each type are almost the same as those in Section 7.2 The consideration on whether ISO/IEC 24761 should be used is almost the same as that in Section 7.2 for the first two types except that the value keyGeneration shall be taken for the field useBiometrics in the cAC product report But for the exclusive type, partial application of ISO/IEC 24761 is recommended to the cAC product in order to show the integrity of the processed biometric sample received by the cAC product In this case, the Biometric Process Block specified in ISO/IEC 24761 should be applied in the cAC instance The data structure of extended cAC instance is almost the same as depicted in Fig except that no BRT certificate is contained because no biometric template is used in this scheme 7.4 Future works In this paper, there is an assumption that the Verifier trusts the cAC product manufacturer This is a strong assumption because it is difficult for the Verifier to know all the cAC product manufacturers that are trusted beforehand It is desirable to weaken this assumption If there are trusted third parties (TTPs) which assure the security of cAC products and issue the digital evidence with which the Verifier can verify cAC product reports, then the Verifier only has to trust these TTPs and that will weaken the assumption given that the number of such TTPs is sufficiently small Evaluation organizations in an alliance of products may be candidates of such TTP Certification bodies in Common Criteria (CC) (Common Criteria Recognition Arrangement, 2012) scheme are also candidates where CC is a scheme for security evaluation and certification of IT products CC is also internationally standardized as ISO/IEC 15408 (ISO/IEC 15408-1, 2012) Please cite this article in press as: Asahiko Yamada, Tatsuro Ikeda, Enhanced PKI authentication with trusted product at claimant, computers & security (2017), doi: 10.1016/ j.cose.2017.01.001 ARTICLE IN PRESS 10 computers & security ■■ (2017) ■■–■■ (a) private key cAC product private key (b) cAC product (c) private key cAC product Fig – Types of relation between biometric processing and cAC product in signature scheme with a fuzzy private key It should be considered how the digital evidence of assurance by such TPPs is expressed If such TPPs assure the security of cAC products, then there are a certain set of security requirements the cAC products shall satisfy Such a set of security requirements can be identified with an identifier if it is assigned uniquely worldwide In the CC world, such a set is made as a Protection Profile (PP) for each category of security related product and there is a movement to specify collaborative Protection Profile (cPP) to share PPs among the countries which belong to CC Recognition Arrangement (CCRA) At the time of writing this paper, Full Disk Encryption cPPs are posted for comments and also an activity is starting to make a cPP for biometric verification products For informing security features of a CC certified product conformant to cPPs, it is appropriate to show the identifiers of the cPPs Let Requirements be a type defined as follows: Here Requirement is used to assign an object identifier to a set of security requirements to the product category Then the type Requirements can mean sets of security requirements which a product satisfies Let ContentProductCert be a type defined as follows: and let id-content-productCert be the object identifier for the type ContentProductCert Then the type ProductCert defined as SIGNEDDATA(id-content-productCert, ContentProductCert) is used to express the digital evidence of a TTP to assure the security of a product if the private key of the TPP is used to digitally sign in generating data of this type The operation of the verification of this digital evidence will be easy to deal with for the Verifier since it is assumed that the number of such TTPs is sufficiently small and the Verifier only has to prepare for X.509 certificates of those TTPs in advance For the case of CC, there are only seventeen CC certification authorities worldwide (see http://www commoncriteriaportal.org/ccra/members/) When ProductCert becomes commonly used, the redefinition of type ContentCPRPssphrs and others adding a new field of type ProductCert will make the cAC product report more trustable data to the Verifier As is written at the end of Section 5, the communication protocol including negotiation is not discussed and to be specified in the next step Adding new authentication contexts corresponding to cAC authentications to the OASIS standard related to authentication context is also necessary Conclusion A new data cAC instance is proposed to improve the authentication process between the Claimant and the Verifier in PKI authentication by giving the evidence data of execution of authentication process at the Claimant To realize this proposal, standardization activities on the specification of cAC instance, the authentication protocol applying cAC authentication are necessary as the next steps Please cite this article in press as: Asahiko Yamada, Tatsuro Ikeda, Enhanced PKI authentication with trusted product at claimant, computers & security (2017), doi: 10.1016/ j.cose.2017.01.001 ARTICLE IN PRESS computers & security ■■ (2017) ■■–■■ REFERENCES Bechelli L, Bistarelli S, Vaccarelli A Biometrics authentication with smartcard Technical Report IIT TR -8/2002, Istituto di Informatica e Telematica (IIT), Istituto di Informatica e Telematica (IIT), 2002 Common Criteria Recognition Arrangement Common criteria for information technology security evaluation, part 1: introduction and general model, September 2012, Version 3.1 Revision 4, CCMB-2012-09-001, 2012 ETSI European Telecommunications Standards Institute (ETSI) ETSI TS 101 862 V1.3.1 Qualified Certificate profile, 2004 European Union Directive 1999/93/EC of the European Parliament and of the Council of 13 December 1999 on a Community framework for electronic signatures, 2000 Hachez G, Koeune F, Quisquater J-J Biometrics, access control, smart cards: a not so simple combination In: Watson A, Domingo-Ferrer J, Chan D, editors Fourth working conference on smart card research and advanced applications (CARDIS 2000), volume 180 of IFIP Conference Proceedings, vol Berlin: Kluwer Academic Publishers; 2000 p 273–88 Hoffman P, Schaad J Requests for Comments (RFC) 5911, New ASN.1 Modules for Cryptographic Message Syntax (CMS) and S/MIME, The Internet Engineering Task Force (IETF), 2010 Housley R Requests for Comments (RFC) 3852, Cryptographic Message Syntax (CMS), The Internet Engineering Task Force (IETF), 2004 ISO/IEC 15408-1 Information technology – Security techniques – Evaluation criteria for IT security – Part 1: Introduction and general model, 2012 ISO/IEC 19785-3 Information technology – Common Biometric Exchange Formats Framework – Part 3: Patron format specifications, 2007 ISO/IEC 19790 Information technology – Security techniques – Security requirements for cryptographic modules, 2012 ISO/IEC 24761 Information technology – Security techniques – Authentication context for biometrics, 2009 ISO/IEC 24761 2009/Cor 1:2013, 2013 ISO/IEC 7816-4 Identification cards – Integrated circuit cards – Part 4: organization, security and commands for interchange, 2013 11 ISO/IEC 7816-8 Identification cards – Integrated circuit card – Part 8: commands for security operations, 2004 National Institute of Standards and Technology Federal Information Processing Standardization (FIPS) 140-2, 2001 National Institute of Standards and Technology NIST Special Publication (SP) 800-63-2 Electronic Authentication Guideline, 2013 Office of Management and Budget E-Authentication Guidance for Federal Agencies, M-04-04, 2003 Ratha NK, Connell JH, Bolle RM A biometrics-based secure authentication system, Proc of IEEE Workshop on Automatic Identification Advanced Technologies (AutoId 99), Summit, NJ, pp 70–73, 1999 Sakimura N, Bradley J, Jones M, de Medeiros B, Mortimore C OpenID Connect Core 1.0 incorporating errata set 1, OpenID Foundation, 2014 Santesson S, Nystrom M, Polk T Requests for Comments (RFC) 3739, Internet X.509 Public Key Infrastructure: Qualified Certificates Profile, The Internet Engineering Task Force (IETF), 2004 SAML, OASIS Advancing open standards for the information society (OASIS) Authentication context for the OASIS Security Assertion Markup Language (SAML) V2.0, OASIS Standard, 2005 Takahashi K, Matsuda T, Murakami T, Hanaoka G, Nishigaki M A Signature Scheme with a Fuzzy Private Key, Proceedings of the 13th international conference on applied cryptography and network security (ACNS 2015), pp.105–126, 2015 Asahiko Yamada is a researcher of Information Technology Research Institute in National Institute of Advanced Industrial Science and Technology (AIST) from 2013 After he received Doctor of Science in 1986 from Sophia University, he worked in Toshiba Corporation for about 30 years He is interested in security technologies related to biometrics Tatsuro Ikeda is an engineer of Information Security at Toshiba, Japan He received his Master of Information Science in 1999 from Yokohama National University (YNU) His research interests include the security of critical infrastructure and biometric authentication, access control technologies Please cite this article in press as: Asahiko Yamada, Tatsuro Ikeda, Enhanced PKI authentication with trusted product at claimant, computers & security (2017), doi: 10.1016/ j.cose.2017.01.001 ... product authentication and user authentication techniques, PKI based user authentication assured by PKI based product authentication Authentication protocol for cAC authentication is also discussed.The... proposed to enhance the PKI authentication pro- Please cite this article in press as: Asahiko Yamada, Tatsuro Ikeda, Enhanced PKI authentication with trusted product at claimant, computers & security... the condition that a trusted product with assumptions from (A) to (F) is used at the Claimant Hereafter a trusted product with the assumptions is called a cAC product and authentication using cAC