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

Trang 1

Enhanced PKI authentication with trusted

product at claimant

Asahiko Yamadaa ,*, Tatsuro Ikedab

aNational Institute of Advanced Industrial Science and Technology, 2-3-26 Aomi, Koto-ku, Tokyo 135-0064, Japan

bToshiba Corporation, 72-34, Horikawa-cho, Saiwai-ku, Kawasaki 212-8585, Japan

A R T I C L E I N F O

Article history:

Available online

A B S T R A C T

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 Claim-ant 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 struc-ture 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, stan-dardization activities are to be considered as the next steps

CC BY-NC-ND license (http://creativecommons.org/licenses/by-nc-nd/4.0/)

Keywords:

Authentication

Biometric

CMS

Digital signature

IC card

PKI

Tamper-resilient software

Tamper-resistant hardware

Trusted device

1 Introduction

In networked IT environments, remote authentication is

es-sential Remote authentication is one of the most important

elements of the security of innumerous applications of

gov-ernmental, commercial, academic systems and so forth and

is applied to such systems Although policy-based

authoriza-tion 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

au-thentication protocol is executed is not taken into account

appropriately and sufficiently This paper proposes a

mecha-nism with which the Verifier can know the level of trust in the

authentication process executed at the Claimant of PKI

au-thentication 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 char-acteristic is provided This case is also discussed later in this paper

2 Current technologies

Progresses in authentication technologies have been signifi-cant 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

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/

Available online at www.sciencedirect.com

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

ScienceDirect

Trang 2

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

authentica-tion 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)

proto-col 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

some-thing you are

In SAML, authentication context is optionally used in

asser-tions 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

authentica-tion context, considering that the execuauthentica-tion 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

suffi-cient 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

cer-tificate 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

Assur-ance (LoA) from Level 1 to Level 4 each of which was introduced

in OMB M-04-04 (Office of Management and Budget, 2003)

Al-though SP 800-63-2 requires Level 4 to use Multi-Factor (MF)

hardware cryptographic token such as tamper-resistant

cryp-tographic 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

unneces-sary 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

Pro-vider (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

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 motiva-tion and a solumotiva-tion 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 gener-alization 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 deci-sion to decide match or non-match from the score (seeFig 1) The second is that the enrolled biometric reference template may be replaced with that of another person such as an at-tacker 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 au-thentication, called Match on Card in the paper but currently called on-card biometric comparison in general, with the as-sumption 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 verifica-tion 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 manu-facturer) has to generate a BPU report to the BPU product in ACBio authentication where it is assumed that the BPU manu-facturer 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/

Trang 3

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

con-tained 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

en-rolment generates its ACBio instance for enen-rolment The ACBio

instances for enrolment show the BPUs used in the

enrol-ment 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

certifi-cate From the ACBio instances for enrolment, the BPU where

the BRT is stored is also identified ACBio instances for

enrol-ment may be used to check whether the enrolenrol-ment satisfies

the security requirement by the BRT certificate authority to issue

the BRT certificate, and also by the Verifier later in

authenti-cation 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 2overviews the data

structure of ACBio instance

An ACBio instance contains the BPU report This gives

in-formation 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

sig-nature to them with the private key of the BPU used

ACBio instance gives the evidence of the successful

execu-tion of the authenticaexecu-tion 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 ex-ecuted 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 authenti-cation 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 inFig 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 inFig 3 Hash value in the left ACBio in-stance 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 Veri-fier can conclude that the integrity of the transmission is kept

data

capture

comparison

storage

comparison decision decision

processed biometric reference

comparison score

processed biometric sample

raw biometric

sample

intermediate biometric sample intermediate

signal processing

final signal processing

Fig 1 – Subprocesses and data flows in biometric authentication.

ACBio instance BPU report

BRT certificate (present only if BPU contains BRT)

Information about BPU X.509 certificate of BPU manufacturer

Signature value

Information about BRT

X.509 certificate of BRT certificate authority

Signature value

X.509 certificate of BPU Signature value

Challenge

Biometric Process Block (Information about the data transmitted between BPUs )

ACBio instance for enrolment (optional)

Fig 2 – Simplified data structure of ACBio instance.

Trang 4

if the pair of Algorithm identifier and Hash value in the left

ACBio instance is the same as that in the right ACBio

in-stance 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 inSection 2,

au-thentication context in SAML is information in assertions, i.e.,

information sent from the Verifier to the RP while ACBio

in-stance 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

pos-sibilities 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 inSection 5 There

should be an authentication protocol for the Verifier to

dis-tinguish 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 gen-erated 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 prod-ucts, 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 digi-tally 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 produc-tion process Therefore the assumpproduc-tion (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 implemen-tation of (F) is not difficult as is to be seen later

In the following, the detailed communication protocol in-cluding negotiation is not discussed

6 Proposal

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

ACBio instance generated by BPU1 Biometric Process Block

Information on output from BPU

Hash information Algorithm identifier Hash value

ACBio instance generated by BPU2 Biometric Process Block

Information on input to BPU

Hash information Algorithm identifier Hash value

Fig 3 – Outline of the mechanism on Biometric Process Block.

Trang 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

com-bination of product authentication and user authentication

techniques, PKI based user authentication assured by PKI based

product authentication Authentication protocol for cAC

au-thentication 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

implementa-tions 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

authentica-tion 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

certificateMnfdenotes 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 IDENTIFIERtype 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

IDEN-TIFIER 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

hard-ware 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 reqLengthPssPhrsand 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 nota-tion, 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 eCTypeIDand 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 There-fore 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 manu-facturer The name of the cAC product manufacturer in the field subjectshall 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 gen-erated 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 certifi-cate 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/

Trang 6

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)

Fur-thermore 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

cer-tificate 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

pro-tocol in order to prevent replay attacks This assumption is

appropriate since the protocols used in PKI authentication

gen-erally 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

ChallengeSignedByUseris generated at the Claimant setting

the challenge of type OCTET STRING into eContent and

digi-tally 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-contentClientACis 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 4shows 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:

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 imple-mented on the cAC product By checking the cAC product report, the Verifier can know whether the cAC product sat-isfies 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 chal-lenge 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 in-stance 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 calcu-lated 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

inSection 4 Fig 5summarizes all the operations in all the processes that are proposed in this paper In the region of processing in cAC product inFig 5, surrounded by the dotted line, the relations

of “contained” and “digitally sign” are assured by the assump-tion from (A) to (F) These make the evidence of the execuassump-tion

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 differ-ence 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 correspond-ing 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-based authorization Therefore the proposed model is more

cAC instance

cAC product report

CSBU

Data of type ContentCPRPassphrase

X.509 certificate of cAC product manufacturer

Signature value

Challenge X.509 certificate of user Signature value

X.509 certificate of cAC product Signature value

Fig 4 – Overview of data structure of cAC instance.

Trang 7

appropriate for the policy-based authorization than the

Quali-fied 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

modifica-tion There are two possibilities in the modification depending

on the security policy on authentication and also on the

imple-mentation of biometric authentication in relation to the cAC

product

The relation between the implementation of biometric

au-thentication 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) inFig 6) The second type is biometric

au-thentication 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

classi-fied as type (c) (see the dotted area inFig 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 tem-plate, 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 au-thentication 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 imple-mentation 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 (seehttp://morix-ic.com/en/) But the authors do not know whether it also has a digital sig-nature 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 inSection 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) inFig 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 au-thentication is executed outside of the cAC product It is easy

Fig 5 – Trust relation in cAC authentication.

Trang 8

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 inSection 3, apply For

the Verifier to trust the result of PKI authentication, it should

be also shown whether the whole biometric processing is

se-curely executed

As described inSection 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

implemen-tation of biometric authentication is inclusive to cAC product,

the use of ISO/IEC 24761 is not necessary because the

execu-tion 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

rec-ommended 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

recom-mended.Table 1summarizes 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 biomet-rics is used for private key generation which is discussed later

inSection 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

(a)

(b)

(c)

cAC product

Fig 6 – Types of relation between biometric authentication and cAC product.

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 Optional –

Non-inclusive to cAC product Recommended Recommended Exclusive to cAC product – 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/

Trang 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

authentica-tion non-inclusive to cAC product, ACBio instance(s) should be

generated by product(s) other than the cAC product If the

Veri-fier needs to validate the biometric processing executed in the

cAC product through the authentication protocol, generation

of an ACBio instance is recommended as written inTable 1but

it is redundant to use ACBio instance as is defined To deal with

this issue, ContentCPRBiometicsDetail shall be defined as

follows to replace ContentCPRBiometicsSimple:

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

re-garded as an extension of BPU report with three fields,

productType, levelCMVPand useBiometrics, added to the

data structure of BPUReportContentInformation in a BPU

report

In registration process, X.509 certificate and BRT

certifi-cate 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

PKICertificateInformationin the BRT certificate This

cor-relates PKI authentication and biometric authentication in

ISO/IEC 24761

In authentication process, extended cAC instance whose data

structure is depicted inFig 7shall 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

au-thentication and ACBio auau-thentication 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

gen-erated 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 pro-cessing and the cAC product is classified into three types, inclusive, non-inclusive, and exclusive, from the view point of this paper, as depicted inFig 8 The three types are similar

to those defined inSection 7.2 Here again (b) inFig 8is 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 inSection 7.2 The consideration on whether ISO/IEC 24761 should be used

is almost the same as that inSection 7.2for the first two types except that the value keyGeneration shall be taken for the field useBiometrics in the cAC product report But for the ex-clusive type, partial application of ISO/IEC 24761 is recommended to the cAC product in order to show the integ-rity 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 de-picted inFig 8except 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 se-curity 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 Evalu-ation organizEvalu-ations 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-dardized as ISO/IEC 15408 (ISO/IEC 15408-1, 2012)

extended cAC instance /extended ACBio instance extended cAC product report/extended BPU report

BRT certificate (optional)

Data of type ContentCPRBiometicsDetail X.509 certificate of cAC product/BPU manufacturer

Signature value

X.509 certificate of cAC product/BPU

Signature value

Biometric Process Block CSBU (as in Fig.4)

Fig 7 – Overview of data structure of extended cAC instance.

Trang 10

It should be considered how the digital evidence of

assur-ance by such TPPs is expressed If such TPPs assure the security

of cAC products, then there are a certain set of security

re-quirements the cAC products shall satisfy Such a set of security

requirements can be identified with an identifier if it is

as-signed 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

Pro-tection 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

com-ments and also an activity is starting to make a cPP for

biometric verification products For informing security

fea-tures 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

require-ments 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 evi-dence 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 evi-dence 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 redefi-nition 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 ofSection 5, the communication protocol including negotiation is not discussed and to be speci-fied 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 authen-tication process between the Claimant and the Verifier in PKI authentication by giving the evidence data of execution of au-thentication process at the Claimant To realize this proposal, standardization activities on the specification of cAC in-stance, the authentication protocol applying cAC authentication are necessary as the next steps

(a)

(b)

(c)

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.

Định dạng
Số trang	11
Dung lượng	1,16 MB