Asahiko Yamada
email: yamada.asahiko@aist.go.jp

A Generalization of ISO/IEC 24761 to Enhance Remote Authentication with Trusted Product at Claimant

Keywords: Biometric authentication, Cryptographic Message Syntax (CMS), digital signature, IC card, initial authentication, Public Key Infrastructure (PKI), remote authentication, tamper-resistant device, trusted device

ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

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 it is applied to them. 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 remote authentication under the condition that a trusted product with the digital signature generation function such as a tamper-resistant IC card is used for 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.

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) and OpenID have made general service providers free from authentication itself and only consume the assertion generated by the Verifier, which is called Identity Provider (IdP) in SAML and OpenID Provider (OP) in OpendID. 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 [1], 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 tamperresistant IC card can be distinguished with the qualified certificate specified in RFC 3739 [START_REF] Santesson | Requests for Comments (RFC) 3739, Internet X.509 Public Key Infrastructure: Qualified Certificates Profile[END_REF] with the qualified certificate statement 5.2.4 in ETSI TS 101 862 [3] 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 [START_REF][END_REF]. But the purpose of X.509 certificate itself is to describe the attributes of the user and his/her public key. So the use of the extension of X.509 certificate in such ways 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 [START_REF]Electronic Authentication Guideline[END_REF]. 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 [START_REF]E-Authentication Guidance for Federal Agencies[END_REF]. 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 or not, and it is not evident either to the Verifier whether such a product is used in authentication process or not, 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 motivation and the solution can be found in ISO/IEC 24761 Authentication Context for Biometrics (ACBio) [START_REF]2009, Information technology -Security techniques -Authentication context for biometrics[END_REF]. The work in this paper is a generalization of the idea in ISO/IEC 24761.

In the following, terms and definitions in SP 800-63-2 are basically applied unless otherwise specified.

ISO/IEC 24761, a related work in biometric authentication

ISO/IEC 24761 referred as ACBio is an enhancement using evidence data generated by execution environment for biometric authentication while this proposal is that for PKI based authentication.

ACBio is a solution to the technological issues of biometric authentication used in the Internet environment. The issues are listed in the threat analysis done in [START_REF] Ratha | A biometrics-based secure authentication system[END_REF] and they are categorized into three. The first is that subprocesses may be replaced with malware. Here a subprocesses is an execution component in biometric authentication, namely data capture to sense human body to output raw biometric sample, intermediate signal processing to process raw biometric sample to intermediate processed biometric sample, final signal processing to process intermediate biometric sample to processed biometric sample, storage to store and retrieve enroled 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 nonmatch from the score. The second is that the enroled 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.

ACBio has solved these issues by generation and verification of evidence data of the executed biometric processing under the assumption that trusted biometric products are used. Authentication using the specification of ACBio is called ACBio authentication. A trusted biometric product is called a Biometric Processing Unit (BPU) in ACBio.

In production process, the BPU manufacturer has to generate the BPU report to BPU product in ACBio authentication. In the BPU report which is a data of type SignedData digitally signed by the BPU manufacture, information about the BPU such as the modality which the BPU processes, the subprocesses implemented and the data flow in the BPU are 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. The data generated at production process are all stored in the BPU.

At registration process, Biometric Reference Template (BRT) certificate is issued to BRT by BRT certificate authority in ACBio authentication. The BRT certificate is a digitally signed data 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 an 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 or not 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. An ACBio instance is generated in each BPU which takes part in biometric authentication process. Fig. 1 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.

The triple of the challenge which is called Control Value in ACBio, the Biometric Process Block, and the BRT certificate, which is contained only if the BPU stores the BRT, is contained in an ACBio instance. This shows that the authentication process at the Claimant is successfully executed.

The ACBio instance contains all the data mentioned above and the digital signature of those with the private key of the BPU. This gives the evidence of the successful execution of the authentication protocol done at the Claimant.

Toshiba Solutions Corporation in Japan has already implemented ACBio authentication into a product. Using this product, its customer company has built an in-house system.

The idea of ACBio enhances biometric authentication used in the Internet but the name ACBio (Authentication Context for Biometrics) is inappropriate. As written in 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 form the Claimant to the Verifier. In this context, the name cAC (client Authentication Context) is used in this paper.

Problem definition

In an environment where a trusted product is not used at the Claimant for PKI based 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 5. There should be an authentication protocol for the Verifier to distinguish the above two cases.

Assumptions

In this paper, suppose 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 triples of private key, public 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 assumption to the trusted products, assume 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 such as 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 [START_REF]-Part 4: Organization, security and commands for interchange[END_REF] and 8 [6] 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.

Proposal

In this paper, a data structure named client Authentication Context (cAC) is proposed to enhance the PKI based authentication protocol 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 or not. 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.

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 have 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 by the cAC product manufacturer, cAC product report becomes a trusted data if there is an assumption that the Verifier trusts the cAC product manufacturer. Hereafter certificateMnf denotes the X.509 certificate 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 [START_REF] Housley | Requests for Comments (RFC) 3852, Cryptographic Message Syntax (CMS) , The Internet Engineering Task Force (IETF)[END_REF] /RFC 5911 [START_REF] Hoffman | Requests for Comments (RFC) 5911[END_REF] 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.

There are some categories of cAC products. For example, in a category, a cAC products activates the private key with a passphrase, in another it may activate the private key with biometric authentication. Here only the former category is discussed. The latter will be discussed later.

There is another categorization of products into a category of software and one of hardware.

The type identifier for the content of cAC product report is defined as id-content-cPR-passphrase of type OBJECT IDENTIFIER. The corresponding content type ContentCPRPassphrase identified by id-content-cPR-passphrase, is define to have four fields. The first field productType gives information that the product is a software or hardware product. The second field levelCMVP is to show the level of Cryptographic Module Validation Program specified in FIPS 140-2 [START_REF]Federal Information Processing Standardization[END_REF] and ISO/IEC 19790 [START_REF]Information technology -Security techniques -Security requirements for cryptographic modules[END_REF] if the cryptographic module in the cAC product is certified. The third reqLengthPassPhrase 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, ContentCPRPassphrase is specified as follows: Let SIGNEDDATA(eCTypeID, ContentType) denote a type which is derived from SignedData where the fields eContentType in encapContentInfo is specified to take eCTypeID and eContent in encapContentInfo is OCTET STRING of the DER encoding of a data of type ContentType.

Then a type CACProductReport for cAC product report is defined as SIGENDDATA(id-content-cPR-passphrase, ContentCPRPassphrase). A 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 public key pair and the X.509 certificate shall be stored in the cAC product together with the already generated cAC product report.

Registration process

To become a Claimant in PKI based authentication process, a user has to generate the public key pair and get the X.509 certificate. 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 is 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 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).

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 most of the protocols used in remote authentication 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, a data of type ChallengeSignedByUser is generated at the Claimant setting the challenge of type OCTET STRING into eContent and digitally signing with the user's private key which is activated with a passphrase input by the user. Hereafter a data of type ChallengeSignedByUser is called a CSBU. A type ContentClientAC identified by the type identifier id-contentClientAC is defined as:

ContentClientAC :: = SEQUENCE { cACProductReport CACProductReport, 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 certificatePrd. Fig. 2 shows a simplified data structure of cAC instance where shaded boxes indicate data specified in 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 if 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 or not by checking the challenge in the CSBU, and whether the Claimant generated the digital signature or not. 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 4.

Fig. 3 summarizes all the operations in all the processes that are proposed in this paper. In the region of processing in cAC product in Fig. 3 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.

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. For the CA to revoke the qualified certificates, the information about the trusted product has to be stored 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 appropriate for the policy-based authorization than the qualified certificate model. Here BiometricType and BiometricSubtype are types for modalities defined in ISO/IEC 19785-3 [START_REF]2007, Information technology -Common Biometric Exchange Formats Framework -Part 3: Patron format specifications[END_REF]. This is the simplest case of the application of cAC to BHSM.

If the Verifier needs to validate the biometric authentication executed in the BHSM through the authentication protocol, the combination of cAC and ACBio will be required. This is the most complex case of the application of cAC to BHSM. To deal with this issue, ContentCPRBiometicsFull shall be defined as follows to replace ContentCPRBiometicsSimple:

ContentCPRBiometicsFull ::= SEQUENCE { productType ProductType, levelCMVP LevelCMVP, bpuFunctionReport BPUFunctionReport, bpuSecurityReport BPUSecurityReport}

Here BPUFunctionReport and BPUSecurityReport are types defined in AC-Bio to show the specification of function and security of BPU. In this case, a BHSM is also considered as a BPU from the view point of ACBio. A cAC product report with ContentCPRBiometicsFull is regarded as an extension of BPU report with two fields, productType and levelCMVP, 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 will be done at different TTPs. In ACBio, 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 referenced with the field pkiCertificateInformation of type PKICertificateInformation in the BRT certificate. This correlates PKI authentication and biometric authentication. In authentication process, extended cAC instance whose data structure is depicted in Fig. 4 shall be used. The extended cAC instance can be also regarded as extended AC-Bio instance. If it is regarded as extended ACBio instance, the BPU report and the control value shall 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.

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.

For security evaluation and certification of products, there is a scheme Common Criteria (CC) [START_REF]Common Criteria for Information Technology Security Evaluation, Part 1: Introduction and general model[END_REF] which is also internationally standardized as ISO/IEC 15408 [START_REF]2009, Information technology -Security techniques -Evaluation criteria for IT security -Part 1: Introduction and general model[END_REF]. In the CC world, there is a movement to specify collaborative Protection Profile (cPP) to share security requirements for certain categories of security related products. At the time of writing this paper, Full Disk Encryption cPPs are posted for comments. For informing security features of a CC certified product, it is appropriate to show the cPPs which the product conforms to because cPPs are security requirements.

Let CPPsConformantTo be a type defined as follows: CPPsConformantTo ::= SEQUENCE OF IdentifierCPP IdentifierCPP ::= OBJECT IDENTIFIER Here IdentifierCPP is used to assign an object identifier to a cPP. Then the type CPPsConformantTo can mean a set of cPPs which a CC certified product conforms to. Let ContentCCCertificate be a type defined as follows:

ContentCCCertificate::= SEQUENCE { nameProduct Name, cPPsConformantTo CPPsConformantTo } and let id-content-CCCertificate be the object identifier for the type ContentCCCertificate. Then the type CCCertificate defined as SIGNEDDATA(id-cPPs-ConformantTo,CPPsConformantTo) is used to express a CC certificate of a product if the private key of a CC certificate authority is used to digitally sign in generating a data of this type. The operation of the verification of this digital CC certificate will be easy to deal with for the Verifier since it needs to prepare only seventeen X.509 certificates in advance as there are only seventeen CC certification authorities worldwide (See http://www.commoncriteriaportal.org/ccra/members/). If signed CC certificate is standardized, the Verifier only needs to trust seventeen CC certification authorities. This will weaken the assumption stated at the beginning of this subsection. When CCCertificate becomes commonly used, the redefinition of type ContentCPRPassphrase adding a new field of type CCCertificate will make the cAC product report a more trustable data to the Verifier.

As is written at the end of 5, the communication protocol including negotiation is not discussed and to be specified in the next step. Adding new authentication contexts corresponding to cAC authentications to the OASIS standard related to authentication context is also necessary.

Conclusion

A new data cAC instance is proposed to improve the authentication process between the Claimant and the Verifier in remote 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.

Fig. 1 .

 1 Fig. 1. Simplified data structure of ACBio instance

  the data transmitted between BPUs ) ACBio instance for enrolment (optional)

Fig. 2 .

 2 Fig. 2. Simplified data structure of cAC instance

Fig. 3 .

 3 Fig. 3. Trust relation in cAC authentication

Fig. 4 .

 4 Fig. 4. Simplified data structure of extended cAC instance

Application of the proposal to ITU-T X.1085 | ISO/IEC 17922 BHSM 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 Committee Draft 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 where the modification depends on the security policy on authentication. If only the modality used has to be known by the Verifier, then replacement of

	7.2
		Production	Registration	Authentication
	Verifier
					challenge
		Region of processing in cAC product	contained
	user (Claimant) ContentCPRPassphrase contained	in	digitally sign CACProductReport	cAC CSBU contained with
	key pair cAC product report ContentCPRBiometicsSimple, which is defined as follows, suffices to apply digitally sign key pair X.509 certificate contained digitally sign cAC product cAC to BHSM: Subjects ContentCPRBiometicsSimple ::= SEQUENCE { key pair digitally sign X.509 ceritificate X.509 ceritificate digitally sign contained productType ProductType, contained levelCMVP LevelCMVP, cAC product contained manufacturer biometricType BiometricType, digitally sign biometricSubype BiometricSubtype OPTIONAL }
	CA of X.509 certificate	digitally sign	Private keys of CAs

Acknowledgement. The author appreciates Mr. Tatsuro Ikeda of Toshiba Solutions Corporation for a lot of discussions related to this work. Without these discussions, the author could not have reached the basic concept of this proposal.


Mohammed H Almeshekah

Mikhail J Atallah
email: matallah@purdue.edu

Eugene H Spafford

Enhancing Passwords Security using Deceptive Covert Communication

Keywords: Authentication, Smartphone, Deception, Covert Channel

The use of deception to enhance security has shown promising results as a defensive technique. In this paper we present an authentication scheme that better protects users' passwords than in currently deployed password-based schemes, without taxing the users' memory or damaging the user-friendliness of the login process. Our scheme maintains comparability with traditional password-based authentication, without any additional storage requirements, giving service providers the ability to selectively enroll users and fall-back to traditional methods if needed. The scheme utilizes the ubiquity of smartphones; however, unlike previous proposals it does not require registration or connectivity of the phones used. In addition, no long-term secrets are stored in any user's phone, mitigating the consequences of losing it. Our design significantly increases the difficulty of launching a phishing attack by automating the decisions of whether a website should be trusted and introducing additional risk at the adversary side of being detected and deceived. In addition, the scheme is resilient against Man-in-the-Browser (MitB) attacks and compromised client machines. We also introduce a covert communication mechanism between the user's client and the service provider. This can be used to covertly and securely communicate the user's context that comes with the use of this mechanism. The scheme also incorporates the use of deception that makes it possible to dismantle a large-scale attack infrastructure before it succeeds. As an added feature, the scheme gives service providers the ability to have full-transaction authentication. With the use of our scheme, passwords are no longer communicated in plaintext format to the server, adding another layer of protection when secure channels of communication are compromised. Moreover, it gives service providers the ability to deploy risk-based authentication. It introduces the ability to make dynamic multi-level access decisions requiring extra authentication steps when needed. Finally, the scheme's covert channel mechanisms give servers the ability to utilize a user's context information -detecting the use of untrusted networks or whether the login was based on a solicitation email.

Introduction

A recent American Banking Association (ABA) report identified internet banking as the preferred method for customer banking [?]: 62% of customers named online banking as their preferred banking method, a substantial rise from 36% in 2010. At the same time, phishing has been an increasing threat -rising at an alarming rate despite all the security mechanisms banks have in place. Criminals have been stealing money by means of exploiting the ubiquity of online banking. It is estimated that the Zeus trojan alone resulted in $70 million dollars stolen from bank accounts [?]. Many of the currently deployed two factor authentication schemes by banks remain vulnerable to a number of attacks [?]. Zeus managed to bypass two factor authentication schemes employed by banks [?]. Adham et al. presented a prototype of a browser add-ons that, even with two factor authentication, can successfully manipulate banking transactions onthe-fly [?]. There is clearly a need to improve the currently deployed schemes and address their shortcomings.

Deployed schemes need to tackle the issues of stolen credentials and phishing, and to mitigate man-in-middle (MitM) and man-in-the-browser (MitB) attacks -we discuss these two attacks in the next section. In this paper we present a mechanism that address these challenges. The scheme has the following desirable characteristics:

1. It automates the decision whether a website should be trusted before the user submits her password. This enhances the ability to detect, and further deceive, an adversary launching a phishing attack by increasing the risk of conducting such attacks. 2. Resilience against the common case of using an untrusted computer and/or network for a login session (e.g., at a hotel lobby or using a guest-account when visiting another organization). 3. A hidden/covert channel facility to convey information to the server about the current authentication context. This can be utilized by the user herself and/or her client -without user involvement. Users can convey their status or doubts they harbor about the trustworthiness of the computer or network they are using for the login session. Users often know that an activity is hazardous yet engage in it nevertheless because of perceived necessity (they need to check their account balance, even in unsafe circumstances). The bank can use this user-conveyed information to grant limited access (e.g., reading account balances and paying utility bills but not carrying out transfers to other bank accounts). 4. Unlike previous schemes, our use of smartphones does not necessitate storing any permanent information on the phone, does not require the phone to have network connectivity or ability to communicate with the computer, and does not require the phone to be registered. It merely uses the smartphone's computing capability. 5. The user-friendly covert channel facility facilitates the use of honeyaccounts through which service providers can learn about the attackers, their methods of operation, which other banks and laundering accounts they use, etc.

Throughout the paper we are using the notion of a bank generically, for two reasons. First, banking is one of the prominent use-cases necessitating the use of secure authentication. Second, banks are quickly becoming the target of choice for malfeasance by evildoers. The scheme we propose is, of course, more generally applicable.

Background

Authentication Schemes

We are concerned with two general classifications of attacks against client-server communication: man-in-the-middle (MitM) and man-in-the-browser (MitB) as shown in figure ??. In the former case, the adversary places herself in the communication channel between the user's computer and the server. End-to-end encryption schemes, such as SSL/TLS and IPSec, are intended to address this so that the adversary cannot observe or alter the data in the communication channel. Attackers overcome this protection by forcing the user to have an endto-end encrypted channel with them instead of the real server, which is the case in phishing attacks. In the latter case, MitB, the attacker places herself between the user and his computer by altering the interface (browser) and manipulates the information displayed to the user in real-time. In this case even if the user employs an end-to-end encryption scheme, such as SSL/TLS, the attacker accesses the information when it is decrypted and can actively modify it before it is shown to the user. . The former can be orchestrated using an active phishing attack, in which the adversary immediately uses the stolen credentials to impersonate the user to the bank, while the latter can be seen, as an example, in the Zeus trojan.

To address the problem of active MitB attacks, banks started to use transaction authentication [?,?]. The Chip Authentication Program (CAP) introduced by many banks requires a piece of dedicated hardware, and its protocol has a number of vulnerabilities [?]. A number of these hardware devices degrade the full transaction authentication to authenticate only part of the transaction, as a consequence of usability challenges [?]. CrontoSign [?] is a smartphone-based fulltransaction authentication that uses the smartphone to verify the information. The scheme requires a new phone registration process that stores information on the phone, which makes the user vulnerable if her phone is compromised or stolen. In addition, it ties the user to a specific phone, hindering the usability of the scheme if the user does not have this particular phone at transaction time. Moreover, this scheme only deals with transaction authentication, and does not focus on providing enhanced user authentication.

Full transaction authentication gives a bank the ability to ask the user to confirm her banking transaction to detect if MitB attacks are taking place and modifying the transaction on-the-fly. It is an essential step to enhance the security of online banking, as pointed out by Adham et al. [?]. The scheme we present in this paper achieves such goals without the need for additional hardware, as in CAP [?] or hPIN/hTAN [?], or for a long term secret stored in the user's smartphone. It also has the other features mentioned earlier, of covertly conveying information to the bank and supporting deceiving the adversary (honeyaccounts).

Use of Smartphones

Clarke et al. were the first to suggest the use of a camera-based device when connecting from untrusted computers [?]. While they did not explicitly discuss the use of QR codes, their paper is considered seminal in this approach of enhancing authentication. A number of follow-on proposals presented other camera-based schemes, using smartphones and other devices to improve authentication (see, e.g., [?,?,?,?,?,?], to mention a few).

Each one of these schemes suffers from one or more of the following shortcomings; (i) requiring an extra piece of hardware; (ii) storage of long-term secret on the smartphone; (iii) requiring a new registration process for associating the user's bank account with a particular smartphone; (iv) requiring the smartphone to have (network or cellular) connectivity to carry out the authentication process. The scheme we present in this paper does not suffer from any of these shortcomings.

Use of Deception and Covert Messages

The use of deception has shown a number of promising results in aiding computer defenses. Almeshekah et al. discussed the advantages of incorporating deception into computer security defenses [?]. We incorporate deceptive elements in our scheme in two ways: (i) active MitM will be deceived such that he is forwarding the covert messages back-and-forth that sends an alarm to the service provider, (ii) we introduce honeyaccounts in our scheme to dismantle an attack before it takes place, and to gather information about the attacker's goals, objectives, and resources.

The covert channel term was introduced by Lampson in 1973 and defined as "channels not intended for information transfer at all" [?]. Such a channel has been extensively studied as a security vulnerability that undermines the security of a system and leaks out private information. The covert channel we are introducing in this scheme is observed to "not carry information" by the adversary and is created by design to enhance the overall security of the system. In this work we are overloading the term, although we see the functionality as similar.

Our method introduces the use of covert deceptive messages between the user and/or her client and the service provider. One of the choices of covert message is that the user is logging in as a response to an email; we discuss how this can be achieved in the next section. If the bank has no record of a recent communication, that response may trigger an enhanced defense, such as enabling read-only access. This would directly address many forms of phishing. Other messages can be automatically embedded by the user's client, such as the use of a public network.

Honeyaccounts are fake bank accounts that banks can use to lure attackers and deceive them into believing that they have successfully broken into the user's account at the bank. They provide an effective mechanism to monitor attackers' activities -to learn who is targeting a certain bank, and learn the other accounts being used to launder users' stolen funds. This information is usually gathered by banks during the forensic investigations following a moneytheft episode (when it is too late to follow the money trail leading overseas). A user who covertly conveys to the bank her belief in the present transaction offers some hope of dismantling the financial infrastructure of a large-scale phishing campaign before it does real damage. We all experience situations where we know that an email is a phishing attempt, yet many of us limit our reaction to not falling prey to it -it would be nice to have an easy-to-use mechanism for conveying our belief and thereby triggering the deception mechanisms of the bank. The covert communication we propose can achieve this.

Technical Specification

This section discusses the technical specifications of our scheme. We show how to perform the initial setup at the server and seamlessly enroll users. We also discuss how the covert channel can be deployed within the authentication scheme. At the end of this section, we discuss some the potential enhancements that our scheme brings which can be incorporated in future work.

Attack Scenarios

There are many attacks against password-based authentication systems including the following common attacks.

-Stolen Passwords. The security of password-based authentication systems fundamentally relies on the fact that each user's password is only known to the user alone. When an adversary obtains the user's password he has the ability to continuously impersonate the user to the server, without any of the two parties noticing. Many attacks, such as phishing, keylogging, and shoulder-surfing are centered on the goal of obtaining users' passwords to gain unbounded access to their accounts. -Stolen Password Hashes File. An adversary who obtains the passwords hashes file of many users can apply an offline cracking process (such as dictionary attacks) to retrieve the users' passwords from their hashes. -Poor/Easily Guessable Passwords. When the user chooses an easily guessable password, an adversary can easily guess it and impersonate the user to the server. -Repeated Password Use. A person may use the same passwords across multiple systems where a compromise against one system undermines the security of all other systems.

The focus of our design is primarily to address the first attack scenario. In addition, it provides a minor improvement to address the problem of cracking passwords.

Scheme -Setup

As depicted in figure ??, there is no new registration required for bank customers, and the bank can roll out the deployment of the scheme either all at once, or progressively by selecting a specific subset of their customers (in which case a user who prefers the old system can easily be accommodated). In addition to a cryptographic one-way hash function H and a cryptographic message authentication code such as HMAC, we use a one-way accumulator function A whose output is to have the same number of bits as H (so that the format of the bank server's password file does not need to be modified -only the nature of the bits stored changes).

As discussed by Fazio and Nicolosi, an accumulator function can be constructed such that it behaves as a one-way function [?]. In addition to the usual one-way property required of cryptographic hashes, a one-way accumulation of n items has the properties that (i) the order of the accumulation does not matter (i.e., any two permutations of the same n items give rise to the same result) [i.e. A(x 1 , x 2 ) = A(x 2 , x 1 )]; and (ii) given a new item/s and the accumulation of a previous item A(x 1 ), a new accumulation that includes the new item/s (as well as the old one) can be efficiently obtained without needing to know the previous item (x 1 ) which equals A(x 1 , new items). To illustrate the second property using an example, if we have the modular exponentiation of x 1 (g x1 ) and we want to compute the new accumulation including a new item x 2 , we compute this as g x x 2 1 = g x1 * x2 . A real world realization of such a function can be done by using a modular exponentiation where the accumulation of x 1 can be implemented as A(x 1 ) = g x1 .

As the most common ways of implementing such an accumulator A function involve modular exponentiation, it is typically the case that A(x, y) = A(x * y) (where arithmetic is modular). In that case the security of A hinges on the Computational Diffie-Hellman assumption: That given A(x 1 ) and A(x 2 ) it is computationally intractable to compute A(x 1 , x 2 ) without knowing either x 1 or x 2 . We give our presentation assuming the existence of such an A, without going into any details of how it is actually implemented (our scheme depends only on A's one-way property, its above-mentioned order-independence, and its above-mentioned incremental accumulation).

Recall that a user's entry in a traditional password file contains h = H(passwd || salt) and salt, where the purpose of the salt bits is to make a wholesale dictionary attack against all users harder (but it does not make it harder to attack an individual user, because the salt is in-the-clear). To switch to the new system, the bank simply replaces h with A(h). This can handle users who select to remain in the traditional username/password authentication (in the obvious way). But replacing h by A(h) is essential for users who select to switch to our proposed smartphone-based scheme, which we describe next.

Scheme -Login

As usual, the login starts with the user entering her username on the computer. We assume that the smartphone has the needed app (which knows nothing about the user or the bank).

-The bank verifies that the username exists and, if so, generates a nonce R.

Then it computes and sends the following information to the user's browser, encoded in a QR-code (recall that a QR code is an optically machine-readable two-dimensional barcode).

• A(R).

• HMAC key (A(R)) where key = A(A(h), R) = A(h, R).

• The user's salt. -The user scans the QR code using the smartphone app and inputs his password to the smartphone. The app computes h = H(password || salt) and then generates the HMAC key by computing A(A(R), h ) = A(R, h )the user's phone does not need a copy of R to make this computation. The HMAC is recomputed locally and then the app verifies that the received HMAC matches the HMAC it just computed. If the check succeeds (meaning the user entered the correct password and h == h ) the user moves into the next step of the protocol -phase 5. If the check fails there are two scenarios for what comes next: A safe case (branch a), and a decoy case (branch b). With the safe case the scheme continues to phase 5; in the decoy case the scheme jumps to phase 6 to send the MitM/MitB to a honeyaccount. In the latter case, the app can simply skip the covert messaging part if it detects a MitM/MitB impersonating the bank, and either terminate or continue with a honeyaccount. In this case, the failure of the HMAC verification can be treated as a special kind of covert message. -In phase (5), the user is provided with the optional facility to covertly signal a simple message to the server. This covert messaging mechanism enables different behaviors from the current practice of "all-or-nothing" authentication and access. We give users the ability to choose from a fixed set of possible messages they could convey to the server. Giving users the ability to convey their level of trust in the computing or network facilities being used, e.g., using a public or a friend's computer, wireless network at an airport, etc. Later in this section, we show how these messages can be easily embedded in the code generated, in phase (6) of the scheme. Users can use this same facility to covertly request a limited-access login (e.g., read-only), in cases where they are following an email-solicited invitation to login to view an "important message." This covert message can alternatively be realized by other means than the above, such as those proposed by Almeshekah et al.

[?]. -In phase [START_REF] Clarke | The untrusted computer problem and camera-based authentication[END_REF], a one-time code is generated by the smartphone by computing the following accumulation:

y = A(A(R), h, msg 1 , .., msg i ) = A(R, h, msg 1 , .., msg i )
The covert messages are conveyed by setting up the bit of any covert message (of the i possible messages) to one. -In phase [START_REF] Drimer | Optimised to fail: Card readers for online banking[END_REF], the user types the generated code into the computer (copied from the smartphone screen). To make the code readable we can use base64 encoding and selecting the first n characters (the size of n is discussed later). Branch (a) of the previous phase, i.e. the existence of networking facility in the phone, will be discussed shortly. -When the bank receives the code, in phase ( 8), it will check the validity of the code and whether a covert message has been signaled or not. It first accumulates into A(h) the item R, if it matches the y sent by the user sent then login succeeds (and the user did not convey a message), if it does not match y then the bank further accumulates (in turn) every possible covert message until the result matches y (or, if none matches, the login fails). In the safe case, if the bank receives a valid code with no message, phase (9) of the protocol is reached. However, if a message is sent, there are two possible options depending on the message: 1. Take policy-specified action as per to the message conveyed before reaching phase [START_REF] Falcarin | Software Protection. Software[END_REF]. This can incorporate a variety of policies including the requirement of carrying out additional authentication measures or offer limited access. This gives service providers the ability to implement risk-based authentication and access control, and enforce a rich set of policies. 2. Redirect the authentication session to a honeyaccount and, optionally, notifying the user of this access decision.

Length of code (y). As we will discuss below, the accumulator function is a one-way function and its output can be viewed as a random sequence of bits. As a result, the adversary succeeds if he can guess all the characters in this code. If we have 64 possible characters (including alphanumeric characters and symbols), the probability of guessing a single character is 2 -6 . If we set the length of y to 5, the probability of guessing the code y is roughly equal to 2 -30 . In addition, as presented above, the calculation of y includes a random number R. As a result, the adversary gains no advantage by learning any previous runs of the protocol and the value of y as it is a one-way function of a number of variables including a random variable.

Incorporating Deception and Covert Communication

The introduction of covert channels in our scheme gives the user and app the ability to convey a number of pre-determined messages without the knowledge of any party positioning itself at any place in the communication channels. This can be done by appending a number of bits to the input of the accumulation function in step (6). To give an example, assume the protocol is designed to signal two different messages to the server; (i) msg 1 the user is accessing from a new wireless network, (ii) msg 2 the user selected read only access. When the app computes y in step (6) it can append two bits to the hash output as the following; y = A(A(R), h(passwd||salt)||msg 1 ||msg 2 ) where msg 1 and msg 2 are single bits that are set to 1 if the user want to signal this message and 0 if the message is not being signaled.

The multitude of applications that can utilize such a mechanism is large and it incorporates status communication as part of the authentication protocol. For example, the bank can take extra precautions if the user is authenticating from a new networking environment. Another example, is the user can signal duress if he has been threatened and forced to transfer money to other accounts. Duress can be signaled covertly, for example, by measuring rapid changes in the phone's built-in accelerometer where the user can subtly shake his phone during login. Another example to signal duress is when the user presses the physical volume buttons during the authentication process.

Security Analysis

Within our scheme when the bank sends A(R), the only party that can successfully respond with y is one who knows the password and gets the smartphone to compute h = H(password||salt) and thus the code y that is conveyed back to the server. This is true because an adversary who gets A(h) and A(R) is unable to compute y = A(h, R) without knowing either R or h, neither of which is available to the attacker. Also note that, if the credentials database at the bank is leaked, no one can impersonate the user without cracking the passwords, as in traditional password schemes. One minor advantage this scheme provides is that cracking is slower for the adversary because of the introduction of the accumulation function A -it is significantly slower to accumulate every password in the cracking dictionary than to simply hash it.

Central to the security of our scheme is the fact that the only information of use to an adversary (the password) is entered on the cell phone and not on the client computer being used to remotely access the bank. The cell phone has no permanent record of any sensitive information. In addition, the bank's server never contains (even ephemerally) the user's password in the clear, providing a measure of defense against a snooping insider at the bank.

Finally, we point out that there are a number of additional security advantages of entering the user's password in a smartphone application instead of the browser:

-The use of Software Guards. Traditional password based-schemes ask the user to enter her password in the browser running on the client operating system. Current browsers are not self-protected, as identified in [?], and they are a complex piece of software that is exposed to many vulnerabilities. For that, our scheme uses a specific phone application that can have an intrinsic software protection against tampering as illustrated in [?,?]. -Automated Trust Decision. Adversaries using social-engineering attacks to lure users to give up their credentials, such as in the case of phishing, exploit the users' decision-making process by presenting them with legitimatelooking web pages. Our scheme aids users in making trust decision about the authenticity of a web page mandating that the website provides a cryptographic proof of their knowledge of a shared secret; namely the password. This process is done in total transparency to the user and the user is only asked to capture the picture of a QR code. This cryptographic proof can be computed by the web server without the need of explicitly storing the password value and, more importantly, without storing any information on the user's phone. This significantly increases the difficulty of social engineering attacks, such as phishing, as it reverses the game -demanding that the web site provides proof of authenticity before the user logs in. -Smaller Chance for Shoulder-Surfing. Traditionally, users enter their passwords using a large keyboard where shoulder surfing is an easy task for adversaries. Asking the user to input their password on their phone increases the difficulty of such activity.

It worth noting that if the user logs-in to the service provider using a phone browser, our scheme cannot be directly used to scan the QR code as we discussed above. However, the basic protocol and feature can still be applicable with only a change in how the QR is input. This can be achieved by developing a browser extension that can automatically detect a QR code in the webpage and button on the corner of such codes to be clicked by users to launch the authentication app where the QR is automatically read. Nevertheless, the advantages of separating the service login, previously done on the computer, and the authentication process on the phone are slightly degraded. If the phone browser is infected with a MitB trojan, it would be easier to circumvent the security on the scheme as it can communicate directly with the authentication app. However, we note that most security sensitive transactions on a phone are done using dedicated apps that are hardened for a specific application. In addition, the underlying principle of using a covert channel presented in this paper can be incorporated in these dedicated apps.

Scheme -Enhancements

Full-Transaction Authentication -After the user logs in, the same steps can be repeated for every sensitive transaction with two main differences: (i) instead of sending the username, it is the transaction information that is sent, so that the QR code will contain additional information about the transaction details along with the HMAC and the user can verify those details on the app itself and make sure it is what they really want; and (ii) the covert message part can be eliminated, only keeping the part related to the failure of MAC checks. This part can be used, as we discussed before, to lure attackers who are launching MitB attacks manipulating transactions "on-the-fly."

Phone Connectivity -If the smartphone happens to have (optional) network connectivity (step (a) in figure ??), it can spare the user the trouble of manually entering the code displayed on its screen, and send it itself to the bank's server (user sessions can be uniquely identified by the server using the nonce R). created. However, when the user verifies this information on his phone after scanning the QR-code he can see that the transaction details have been changed. He can click on a button to say that the details have been changed and a deceptive code can be generated. The MitB attacker would end up in phase [START_REF] Fazio | Cryptographic accumulators: Definitions, constructions and applications[END_REF] where they will be deceived. Use of special Hardware -many proposals introduce a new piece of hardware to the authentication scheme to achieve a higher level of assurance and to verify banking transactions, such as the CAP scheme [?]. There are two major disadvantages with those approaches: cost and usability. As an illustrative example, Barclay's bank in the UK equipped users with special full-transaction authentication hardware, but ended up having to reduce the functionality to only partial transaction authentication because of many customer complaints. This degradation led to a number of security vulnerabilities [?].

Requiring phone connectivity -a number schemes are intended to maximize their usability by making the smartphone or the special hardware act on the users' behalf. In all the mechanisms we examined this comes with the cost of either requiring the phone to have network connectivity, which is not always possible, or requiring a direct communication between the users' computers and their smartphones, which hinders usability. In our proposal we share the same goals and enhance the usability of our scheme by giving users the ability to login even though they do not have any connectivity in their phone and without having to connect their phones to their computers.

Compatible with existing infrastructure -banks perceive security as an economic and risk reduction activity. Protocols that require radical changes to current infrastructure usually do not get adopted because of the associated high cost. In addition, the ability to dynamically fall back to traditional authentication methods is a preferred property giving banks the ability to dynamically deploy their new scheme and progressively enroll their users. This is why we use this as a comparison factor with other schemes.

Conclusion

We propose an authentication mechanism that has many attractive features, including compatibility with deployed authentication infrastructure; flexible use of smartphones without requiring phone registration or storage of permanent information in the phone; without any requirement of phone connectivity (i.e., using the phone as a computational device rather than as a storage or communication device); resistance to many common forms of attack; and a facility for user-friendly (pull-down menu on the cell phone app) covert communication from the user to the bank. The covert communication in turn makes possible different levels of access (instead of the traditional all-or-nothing), and the use of deception (honeyaccounts) that makes it possible to dismantle a large-scale attack infrastructure before it succeeds (rather than after the painful and slow forensics that follow a successful phishing attack).

Fig. 1 .

 1 Fig. 1. Man-in-the-Middle (MitM) vs. Man-in-the-Browser (MitB)

Fig. 2 .

 2 Fig. 2. Protocol Run

Table 1 .

 1 Schemes Comparison

		no	no	resists MitB no	no	compatible
		phone	long-	special	phone	with exist-
		enroll-	term	hard-	connec-	ing
		ment	secret	ware	tivity
	Our Scheme
	CrontoSign [?] -	-			-
	QR-Tan [?]	-	-			-
	hPin/hTan [?] N/A	-	-	N/A	-
	QRP [?]	-	-			-

Storage of Insensitive Information -The security of our scheme does not require the long term storage of any information in the phone itself. Nevertheless, we can benefit from storing information that can increase the utility of the covert communication. As an example, the app can store the name(s) of user's home network(s) and automatically send a covert message when the user is using a non-trusted network to login. Such knowledge gives service providers the ability to deploy a risk-based authentication. For example, when the user is using an untrusted network to login, a limited control can be provided and extra level of authentication can be enforced when powerful transactions are required.

Comparison with Other Schemes

In table ?? we evaluate the different schemes using the following criteria.

Requirement of phone enrollment -schemes such as CrontoSign and QRP [?] require the user to register her phone with the bank, i.e. phone enrollment. Such schemes store phone information, such as IMEI number, and use it as part of their protocol to achieve assurances about the user's identity. One of the major issue of tying the user's identity to his phone is that the user may lose his phone, forget it or run out of battery. In these circumstances, the user wants to be able to use an alternative phone to login to his account. If the user loses his phone he is vulnerable to the threat of impersonation until he reports the incident to every bank he banks with. In the case where he does not have his phone the usability of such a scheme becomes an issue as the user cannot login to his account anymore. This could result in lost business if the user moves to other banks that are using more usable schemes.

Our approach addresses these concerns in two ways. First, we allow users to use many phones without degrading the security of the scheme or asking the user to register all his phones. Second, we challenge the all-or-nothing assumption allowing users to fall back to other authentication mechanisms dynamically, possibly setting the privileges to only allow non-sensitive transactions.

Requirement of long-term secrets -many of the previously proposed schemes require the storage of long-term secret(s) either on the users' phones or on another piece of specialized hardware [?,?,?]. To the best of our knowledge, our scheme is the first scheme that provides full transaction authentication and user authentication that resist MitB without the need to store long-term secrets or require additional hardware.

Resisting MitB -a recent paradigm in banking Trojans is to bypass two factor authentication by launching MitB attacks that change transaction information on-the-fly. We compare the schemes in table ?? based on their resistance to MitB. When our scheme is used to authenticate transactions, as discussed in section ??, a MitB attack can be defeated. This is because the MitB needs to send the modified transaction information to the bank, where an HMAC is