Scholarly article on topic 'Enhanced PKI authentication with trusted product at claimant'

Enhanced PKI authentication with trusted product at claimant Academic research paper on "Computer and information sciences"

CC BY-NC-ND
0
0
Share paper
Academic journal
Computers & Security
OECD Field of science
Keywords
{Authentication / Biometric / CMS / "Digital signature" / "IC card" / PKI / "Tamper-resilient software" / "Tamper-resistant hardware" / "Trusted device"}

Abstract of research paper on Computer and information sciences, author of scientific article — Asahiko Yamada, Tatsuro Ikeda

Abstract In this paper, a data structure to enhance PKI (Public Key Infrastructure) authentication is proposed generalizing the concept of ISO/IEC 24761. Current technologies do not provide sufficient information on products which are used in the authentication process at the Claimant to the Verifier. As a result, the Verifier cannot sufficiently distinguish the authentication result executed with a trusted product from that without a trusted product. The difference is made clear if evidence data of the execution of authentication process at the Claimant are generated by the trusted product and used for verification by the Verifier. Data structure for such data is proposed in this paper as client Authentication Context (cAC) instance. Relation to other works and extension of the proposal where biometrics is used are also described for further improvement of PKI authentication. For this proposal to realize, standardization activities are to be considered as the next steps.

Academic research paper on topic "Enhanced PKI authentication with trusted product at claimant"

ARTICLE IN PRESS

computers & security ■■ (2017)

ELSEVIER

Available online at www.sciencedirect.com

ScienceDirect

journal homepage: www.elsevier.com/locate/cose

@ Enhanced PKI authentication with trusted product at claimant

Asahiko Yamada a* Tatsuro Ikeda b

a National Institute of Advanced Industrial Science and Technology, 2-3-26 Aomi, Koto-ku, Tokyo 135-0064, Japan b Toshiba Corporation, 72-34, Horikawa-cho, Saiwai-ku, Kawasaki 212-8585, Japan

Computers &

Security

ARTICLE INFO

ABSTRACT

Article history: Available online

Keywords: Authentication Biometric CMS

Digital signature

IC card

Tamper-resilient software Tamper-resistant hardware Trusted device

In this paper, a data structure to enhance PKI (Public Key Infrastructure) authentication is proposed generalizing the concept of ISO/IEC 24761. Current technologies do not provide sufficient information on products which are used in the authentication process at the Claimant to the Verifier. As a result, the Verifier cannot sufficiently distinguish the authentication result executed with a trusted product from that without a trusted product. The difference is made clear if evidence data of the execution of authentication process at the Claimant are generated by the trusted product and used for verification by the Verifier. Data structure for such data is proposed in this paper as client Authentication Context (cAC) instance. Relation to other works and extension of the proposal where biometrics is used are also described for further improvement of PKI authentication. For this proposal to realize, standardization activities are to be considered as the next steps.

© 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/).

1. 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.

2. 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/jj.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/).

ARTICLE IN PRESS

2 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 ETSITS 101862 (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 1 to Level 4 each of which was introduced in OMB M-04-04 (Office of Management and Budget, 2003). Although SP 800-63-2 requires Level 4 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 4 and it can be assured that such a token is issued and used in authentication process at the Claimant. But in Level 2 and Level 3 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 2 and Level 3, it would be desirable for the RP to know more information about

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.

3. ISO/IEC 24761, a related work in biometric authentication

ISO/IEC 24761 referred as ACBio is an enhancement for bio-metric authentication while this proposal is that for PKI authentication.

ACBio is a solution to the technological issues of biomet-ric 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 sub-process is an execution component in biometric authentication, namely data capture to sense human body to output raw bio-metric 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 bio-metric 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 Bio-metric 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

the trust level of the authentication process executed at the (Housley, 2004; Hoffman and Schaad, 2010) digitally signed with

ARTICLE IN PRESS

computers & security

(2017)

raw biometric

intermediate biometric

processed biometric

comparison decision

Fig. 1 - 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. 2 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 Biomet-ric 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 3. 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. 3. 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. 3. 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. 2 - Simplified data structure of ACBio instance.

ARTICLE IN PRESS

computers & security

(2017)

BPU1 BPU2

ACBio instance generated by BPU1

Biometric Process Block

Information on output from BPU

Hash information I Algorithm identifieT

I Hash value ~

ACBio instance generated by BPU2

Biometric Process Block

Information on input to BPU

Hash information ►I Algorithm identifieT

H Hash value ~

Fig. 3 - 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.

4. 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 5. There should be an authentication protocol for the Verifier to distinguish the above two cases.

5. Assumptions

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.

(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 8 (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.

6. Proposal

In this paper, a data structure named client Authentication Context (cAC) is proposed to enhance the PKI authentication pro-

ARTICLE IN PRESS

computers & security ■■ (2017) ■■ ■■ 5

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

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

of Cryptographic Module Validation Program specified in FIPS "key generating context" in cAC authentication. But it is

ARTICLE IN PRESS

6 computers & security ■■ (2017) ■■ ■■

Fig. 4 - 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 id-contentelientAe is defined as:

ChallengeSignedByUser ChallengeSignedByUser }

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

instance where shaded boxes indicate data imported from RFC 3852.

At the Verifier, a cAC instance is verified as follows:

1. 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.

2. 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.

3. 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 4.

Fig. 5 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.

7. 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 policy-

certificatePrd. Fig. 4 shows a simplified data structure of cAC based authorization. Therefore the proposed model is more

ARTICLE IN PRESS

computers & security ■■ (2017)

Processes

Production

Registration

Verifier

user (Claimant)

■D cAC product (0

cAC product manufacturer 1 Î

CA of X.509 certificate 1

Authentication

challenge

„- Region of processing in cAC product

contained

digitally sigr

key pair

contained

-4 CSBU I

I contained

cAC instance

contained

X.509 certificate

cAC product report

digitally signr

s^gitally sigr

key pain.

contained

key pain

X.509 certificate

digitally sign

X.509 certificate

digitally sign

digitally sign _contained

contalnec digitally sign

Private keys of CAs

Fig. 5 - 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 bio-metric authentication subprocesses are implemented outside of the cAC product. The last type is biometric authentication exclusive to cAC product in the whole biometric subpro-cesses are implemented outside of the cAC product. Fig. 6 depicts the three types where (b) is a typical example of non-inclusive 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 do 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 biomet-ric authentication are executed outside of the cAC product. The processing outside of the cAC product is not trusted in general, as seen in Section 3. 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 subpro-cess functions depicted (b) in Fig. 6. 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

ARTICLE IN PRESS

computers & security ■■ (2017)

intermediate signal processing final signal processing

capture

cAC product

intermediate signal processing

capture

cAC product

" data intermediate signal processing

capture

\ cAC product

Fig. 6 - 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 1 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:

ContentCPRBiometicsSimple ::= SEQUENCE { productType ProductType,

LevelCMVP, UseBiometrics, BiometricType, BiometricSubtype OPTIONAL }

levelCMVP useBiometrics biometricType biometricSubype UseBiometrics ::= ENUMERATED { keyActivation (0), keyGeneration (1) }

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 1 - 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 Use of ISO/IEC 24761

cAC product Outside of cAC product

Inclusive to cAC product Non-inclusive to cAC product Exclusive to cAC product Optional Recommended Recommended Recommended

ARTICLE IN PRESS

computers & security ■■ (2017) ■■ ■■ 9

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 1 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:

ContentCPRBiometicsDetail ::= SEQUENCE {

bpuFunctionReport BPUFunctionReport,

bpuSecurityReport BPUSecurityReport}

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. 7 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

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. 7 - Overview of data structure of extended cAC instance.

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. 8 . The three types are similar to those defined in Section 7.2. Here again (b) in Fig. 8 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. 8 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 suchTTPs 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 stan-

the other biometric authentication technologies. dardized as ISO/IEC 15408 (ISO/IEC 15408-1, 2012).

ARTICLE IN PRESS

computers & security

(2017)

private key

cAC product

private key

cAC product

Fig. 8 - 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:

Requirements ::= SEQUENCE OF Requirement Requirement ::= OBJECT IDENTIFIER

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 aTTP 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.

8. 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.

ARTICLE IN PRESS

computers & security ■■ (2017) ■■ ■■ 11

REFERENCES

Bechelli L, Bistarelli S, Vaccarelli A. Biometrics authentication with smartcard. Technical Report IITTR -8/2002, Istituto di Informatica eTelematica (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). ETSITS 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. 9. 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.

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),

SAML, OASIS. Advancing open standards for the information society (OASIS). Authentication context for the OASIS Security Assertion Markup Language (SAML) V2.0, OASIS Standard,

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.