TOC 
Internet Engineering Task ForceD. M'Raihi
Internet-DraftVerisign, Inc.
Intended status: Standards TrackJ. Rydell
Expires: September 8, 2010Portwise, Inc.
 S. Machani
 Diversinet Corp.
 D. Naccache
 Ecole Normale Superieure
 S. Bajaj
 Verisign, Inc.
 March 07, 2010


OCRA: OATH Challenge-Response Algorithms
draft-mraihi-mutual-oath-hotp-variants-10.txt

Abstract

This document describes an algorithm for challenge-response authentication developed by the "Initiative for Open AuTHentication" [OATH] (Initiative for Open AuTHentication, “OATH Vision,” .). The specified mechanisms leverage the HMAC-based One-Time Password algorithm [RFC4226] (M'Raihi, D., Bellare, M., Hoornaert, F., Naccache, D., and O. Ranen, “HOTP: An HMAC-Based One-Time Password Algorithm,” December 2005.) and offer one-way and mutual authentication capabilities.

Status of this Memo

This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”

The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.

This Internet-Draft will expire on September 8, 2010.

Copyright Notice

Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License.



Table of Contents

1.  Introduction
2.  Notation and Terminology
3.  Algorithm Requirements
4.  OCRA Background
    4.1.  HOTP Algorithm
5.  Definition of OCRA
    5.1.  DataInput Parameters
    5.2.  CryptoFunction
6.  The OCRASuite
    6.1.  Algorithm
    6.2.  CryptoFunction
    6.3.  DataInput
7.  Algorithm Modes for Authentication
    7.1.  One way Challenge-Response
    7.2.  Mutual Challenge-Response
    7.3.  Algorithm Modes for Signature
        7.3.1.  Plain Signature
        7.3.2.  Signature with Server Authentication
8.  Security Considerations
    8.1.  Security Analysis of the OCRA algorithm
    8.2.  Implementation Considerations
9.  IANA Considerations
10.  Conclusion
11.  Acknowledgements
12.  References
    12.1.  Normative references
    12.2.  Informative References
Appendix A.  Reference Implementation
Appendix B.  Test Vectors
    B.1.  Plain challenge response
    B.2.  Mutual Challenge Response
    B.3.  Plain Signature
§  Authors' Addresses




 TOC 

1.  Introduction

OATH has identified several use cases and scenarios that require an asynchronous variant to accommodate users who do not want to maintain a synchronized authentication system. A commonly accepted method for this is to use a challenge-response scheme.

Such challenge response mode of authentication is widely adopted in the industry. Several vendors already offer software applications and hardware devices implementing challenge-response - but each of those uses vendor-specific proprietary algorithms. For the benefits of users there is a need for a standardized challenge-response algorithm which allows multi-sourcing of token purchases and validation systems to facilitate the democratization of strong authentication. Additionally, this specification describes the means to create symmetric key based digital signatures. Such signatures are variants of challenge-response mode where the data to be signed becomes the challenge.



 TOC 

2.  Notation and Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] (, “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).



 TOC 

3.  Algorithm Requirements

This section presents the main requirements that drove this algorithm design. A lot of emphasis was placed on flexibility and usability, under the constraints and specificity of the HOTP algorithm and hardware token capabilities.

R1 - The algorithm MUST support asynchronous challenge-response based authentication.

R2 - The algorithm MUST be capable of supporting symmetric key based digital signatures. Essentially this is a variation of challenge-response where the challenge is derived from the data that need to be signed.

R3 - The algorithm MUST be capable of supporting server- authentication, whereby the user can verify that he/she is talking to a trusted server.

R4 - The algorithm SHOULD use HOTP [RFC4226] (M'Raihi, D., Bellare, M., Hoornaert, F., Naccache, D., and O. Ranen, “HOTP: An HMAC-Based One-Time Password Algorithm,” December 2005.) as a key building block.

R5 - The length and format of the input challenge SHOULD be configurable.

R6 - The output length and format of the generated response SHOULD be configurable.

R7 - The challenge MAY be generated with integrity checking (e.g., parity bits). This will allow tokens with pin pads to perform simple error checking when the user enters the challenge value into a token.

R8 - There MUST be a unique secret (key) for each token/soft token that is shared between the token and the authentication server. The keys MUST be randomly generated or derived using a key derivation algorithm.

R9 - The algorithm MAY enable additional data attributes such as a timestamp or session information to be included in the computation. These data inputs MAY be used individually or all together.



 TOC 

4.  OCRA Background

OATH introduced the HOTP algorithm as a first open, freely available building block towards strengthening authentication for end-users in a variety of applications. One-time passwords are very efficient at solving specific security issues thanks to the dynamic nature of OTP computations.

After carefully analyzing different use cases, OATH came to the conclusion that providing for extensions to the HOTP algorithms was important. A very natural extension is to introduce a challenge mode for computing HOTP values based on random questions. Equally beneficial is being able to perform mutual authentication between two parties, or short-signature computation for authenticating transaction to improve the security of e-commerce applications.



 TOC 

4.1.  HOTP Algorithm

The HOTP algorithm, as defined in [RFC4226] (M'Raihi, D., Bellare, M., Hoornaert, F., Naccache, D., and O. Ranen, “HOTP: An HMAC-Based One-Time Password Algorithm,” December 2005.) is based on an increasing counter value and a static symmetric key known only to the prover and verifier parties.

As a reminder:

 HOTP(K,C) = Truncate(HMAC-SHA1(K,C))

Where Truncate represents the function that converts an HMAC-SHA-1 value into an HOTP value.

We refer the reader to [RFC4226] (M'Raihi, D., Bellare, M., Hoornaert, F., Naccache, D., and O. Ranen, “HOTP: An HMAC-Based One-Time Password Algorithm,” December 2005.) for the full description and further details on the rationale and security analysis of HOTP.

The present draft describes the different variants based on similar constructions as HOTP.



 TOC 

5.  Definition of OCRA

OCRA is a generalization of HOTP with variable data inputs not solely based on an incremented counter and secret key values.

The definition of OCRA requires a cryptographic function, a key K and a set of DataInput parameters. This section first formally introduces the OCRA algorithm and then introduces the definitions and default values recommended for all parameters.

In a nutshell,

 OCRA = CryptoFunction(K, DataInput)

Where:

CryptoFunction is described in details in section Section 5.2 (CryptoFunction)



 TOC 

5.1.  DataInput Parameters

This structure is the concatenation over byte array of the OCRASuite value as defined in section 6 with the different parameters used in the computation, save for the secret key K.

DataInput = {OCRASuite | 00 | C | Q | P | S | T} where:

When computing a response, the concatenation order is always the following:

C |

OTHER-PARTY-GENERATED-CHALLENGE-QUESTION |

YOUR-GENERATED-CHALLENGE-QUESTION |

P| S | T

If a value is empty (i.e. a certain input is not used in the computation) then the value is simply not represented in the string.

The counter on the token or client MUST be incremented every time a new computation is requested by the user. The server's counter value MUST only be incremented after a successful OCRA authentication.



 TOC 

5.2.  CryptoFunction

The default CryptoFunction is HOTP-SHA1-6, i.e. the default mode of computation for OCRA is HOTP with the default 6-digit dynamic truncation and a combination of DataInput values as the message to compute the HMAC-SHA1 digest.

As indicated in section 5.1, we denote t as the length in digits of the truncation output. For instance, if t = 6, then the output of the truncation is a 6-digit value.

We define the HOTP family of functions as an extension to HOTP:

  1. HOTP-H-t: these are the different possible truncated versions of HOTP, using the dynamic truncation method for extracting an HOTP value from the HMAC output
  2. We will denote HOTP-H-t as the realization of an HOTP function that uses an HMAC function with the hash function H, and the dynamic truncation as described in [RFC 4226] to extract a t- digit value
  3. t=0 means that no truncation is performed and the full HMAC value is used for authentication purpose

We list the following preferred modes of computation, where * denotes the default CryptoFunction:

This table summarizes all possible values for the CryptoFunction:



NameHMAC Function UsedSize of Truncation (t)
HOTP-SHA1-t HMAC-SHA1 0 (no truncation), 4-10
HOTP-SHA256-t HMAC-SHA256 0 (no truncation), 4-10
HOTP-SHA512-t HMAC-SHA512 0 (no truncation), 4-10

 Table 1: CryptoFunction Table 



 TOC 

6.  The OCRASuite

An OCRASuite value is a text string that captures one mode of operation for the OCRA algorithm, completely specifying the various options for that computation. An OCRASuite value is represented as follows:

Algorithm:CryptoFunction:DataInput

The client and server need to agree on one or two values of OCRASuite. These values may be agreed at time of token provisioning or for more sophisticated client-server interactions these values may be negotiated for every transaction.

Note that for Mutual Challenge-Response or Signature with Server Authentication modes, the client and server will need to agree on two values of OCRASuite - one for server computation and another for client computation.



 TOC 

6.1.  Algorithm

Description: Indicates the version of OCRA algorithm.

Values: OCRA-v where v represents the version number (e.g. 1, 2 etc.). This document specifies version 1 of the OCRA algorithm.



 TOC 

6.2.  CryptoFunction

Description: Indicates the function used to compute OCRA values

Values: Permitted values are described in section 5.2



 TOC 

6.3.  DataInput

Description: This component of the OCRASuite string captures the list of valid inputs for that computation; [] indicates a value is optional:

[C] | QFxx | [PH | Snnn | TG] : Challenge-Response computation

[C] | QFxx | [PH | TG] : Plain Signature computation

Each input that is used for the computation is represented by a single letter (except Q) and they are separated by a hyphen.

The input for challenge is further qualified by the formats supported by the client for challenge question(s). Supported values can be:



Format (F)Up to Length (xx)
A (alphanumeric) 04-64
N (numeric) 04-64
H (hexadecimal) 04-64

 Table 2: Challenge Format Table 

The default challenge format is N08, numeric and upto 8 digits.

The input for P is further qualified by the hash function used for the PIN/password. Supported values for hash function can be:

Hash function (H) - SHA1, SHA256, SHA512.

The default hash function for P is SHA1.

The input for S is further qualified by the length of the session data in bytes. The client and server could agree to any length but the typical values are:

Length (nnn) - 064, 128, 256 and 512.

The default length is 064 bytes.

The input for timestamps is further qualified by G, size of the time-step. G can be specified in number of seconds, minutes or hours:



Time-step Size (G)Examples
[1-59]S number of seconds, e.g. 20S
[1-59]M number of minutes, e.g. 5M
[0-48]H number of hours, e.g. 24H

 Table 3: Time-step Size Table 

Default value for G is 1M, i.e. time step size is one minute and the T represents the number of minutes since Epoch time.

Here are some examples of OCRASuite strings:



 TOC 

7.  Algorithm Modes for Authentication

This section describes the typical modes in which the above defined computation can be used for authentication.



 TOC 

7.1.  One way Challenge-Response

A challenge/response is a security mechanism in which the verifier presents a question (challenge) to the prover who must provide a valid answer (response) to be authenticated.

To use this algorithm for a one-way challenge-response, the verifier will communicate a challenge value (typically randomly generated) to the prover. The prover will use the challenge in the computation as described above. The prover then communicates the response to the verifier to authenticate.

Therefore in this mode, the typical data inputs will be:

C - Counter, optional.

Q - Challenge question, mandatory, supplied by the verifier.

P - Hashed version of PIN/password, optional.

S - Session information, optional.

T - Timestamp, optional.

The diagram below shows the message exchange between the client (prover) and the server (verifier) to complete a one-way challenge- response authentication.

It is assumed that the client and server have a pre-shared key K that is used for the computation.

 CLIENT                                   SERVER
(PROVER)                                 VERIFIER)
   |                                        |
   |   Verifier sends challenge to prover   |
   |   Challenge = Q                        |
   |<---------------------------------------|
   |                                        |
   |   Prover Computes Response             |
   |   R = OCRA(K, {[C] | Q | [P | S | T]}) |
   |   Prover sends Response = R            |
   |--------------------------------------->|
   |                                        |
   |  Verifier Validates Response           |
   |  If Response is valid, Server sends OK |
   |  If Response is not,  Server sends NOK |
   |<---------------------------------------|
   |                                        |


 TOC 

7.2.  Mutual Challenge-Response

Mutual challenge-response is a variation of one-way challenge- response where both the client and server mutually authenticate each other.

To use this algorithm, the client will first send a random client- challenge to the server. The server computes the server-response and sends it to the client along with a server-challenge.

The client will first verify the server-response to be assured that it is talking to a valid server. It will then compute the client- response and send it to the server to authenticate. The server verifies the client-response to complete the two-way authentication process.

In this mode there are two computations: client-response and server-response. There are two separate challenge questions, generated by both parties. We denote these challenge questions Q1 and Q2.

Typical data inputs for server-response computation will be:

C - Counter, optional.

QC - Challenge question, mandatory, supplied by the client.

QS - Challenge question, mandatory, supplied by the server.

S - Session information, optional.

T - Timestamp, optional.

Typical data inputs for client-response computation will be:

C - Counter, optional.

QS - Challenge question, mandatory, supplied by the server.

QC - Challenge question, mandatory, supplied by the client.

P - Hashed version of PIN/password, optional.

S - Session information, optional.

T - Timestamp, optional.

The following picture shows the messages that are exchanged between the client and the server to complete a two-way mutual challenge- response authentication.

It is assumed that the client and server have a pre-shared key K (or pair of keys if using dual-key mode of computation) that is used for the computation.

 CLIENT                                             SERVER
(PROVER)                                          (VERIFIER)
   |                                                  |
   |   1. Client sends client-challenge               |
   |   QC = Client-challenge                          |
   |------------------------------------------------->|
   |                                                  |
   |   2. Server computes server-response             |
   |      and sends server-challenge                  |
   |   RS = OCRA(K, [C] | QC | QS | [S | T])          |
   |   QS = Server-challenge                          |
   |   Response = RS, QS                              |
   |<-------------------------------------------------|
   |                                                  |
   |   3. Client verifies server-response             |
   |      and computes client-response                |
   |   OCRA(K, [C] | QC | QS | [S | T]) != RS -> STOP |
   |   RC = OCRA(K, [C] | QS | QC | [P | S | T])      |
   |   Response = RC                                  |
   |------------------------------------------------->|
   |                                                  |
   |   4. Server verifies client-response             |
   |   OCRA(K, [C] | QS | QC | [P|S|T]) != RC -> STOP |
   |   Response = OK                                  |
   |<-------------------------------------------------|
   |                                                  |


 TOC 

7.3.  Algorithm Modes for Signature

In this section we describe the typical modes in which the above defined computation can be used for digital signatures.



 TOC 

7.3.1.  Plain Signature

To use this algorithm in plain signature mode, the server will communicate a signature-challenge value to the client (signer). The signature-challenge is either the data to be signed or derived from the data to be signed using a hash function, for example.

The client will use the signature-challenge in the computation as described above. The client then communicates the signature value (response) to the server to authenticate.

Therefore in this mode, the data inputs will be:

C - Counter, optional.

QS - Signature-challenge, mandatory, supplied by the server.

P - Hashed version of PIN/password, optional.

T - Timestamp, optional.

The picture below shows the messages that are exchanged between the client (prover) and the server (verifier) to complete a plain signature operation.

It is assumed that the client and server have a pre-shared key K that is used for the computation.

 CLIENT                                     SERVER
(PROVER)                                  (VERIFIER)
   |                                           |
   |    Verifier sends signature-challenge     |
   |    Challenge = QS                         |
   |<------------------------------------------|
   |                                           |
   |    Client Computes Response               |
   |    SIGN = OCRA(K, [C] | QS | [P | T])     |
   |    Response = SIGN                        |
   |------------------------------------------>|
   |                                           |
   |    Verifier Validates Response            |
   |    Response = OK                          |
   |<------------------------------------------|
   |                                           |


 TOC 

7.3.2.  Signature with Server Authentication

This mode is a variation of the plain signature mode where the client can first authenticates the server before generating a digital signature.

To use this algorithm, the client will first send a random client- challenge to the server. The server computes the server-response and sends it to the client along with a signature-challenge.

The client will first verify the server-response to authenticate that it is talking to a valid server. It will then compute the signature and send it to the server.

In this mode there are two computations: client-signature and server-response.

Typical data inputs for server-response computation will be:

C - Counter, optional.

QC - Challenge question, mandatory, supplied by the client.

QS - Signature-challenge, mandatory, supplied by the server.

T - Timestamp, optional.

Typical data inputs for client-signature computation will be:

C - Counter, optional.

QC - Challenge question, mandatory, supplied by the client.

QS - Signature-challenge, mandatory, supplied by the server.

P - Hashed version of PIN/password, optional.

T - Timestamp, optional.

The diagram below shows the messages that are exchanged between the client and the server to complete a signature with server authentication transaction.

It is assumed that the client and server have a pre-shared key K (or pair of keys if using dual-key mode of computation) that is used for the computation.

 CLIENT                                              SERVER
(PROVER)                                            VERIFIER)
   |                                                   |
   |    1. Client sends client-challenge               |
   |    QC = Client-challenge                          |
   |-------------------------------------------------->|
   |                                                   |
   |    2. Server computes server-response             |
   |       and sends signature-challenge               |
   |    RS = OCRA(K, [C] | QC | QS | [T])              |
   |    QS = signature-challenge                       |
   |    Response = RS, QS                              |
   |<--------------------------------------------------|
   |                                                   |
   |    3. Client verifies server-response             |
   |       and computes signature                      |
   |    OCRA(K, [C] | QC | QS | [T]) != RS -> STOP     |
   |    SIGN = OCRA( K, [C] | QS | QC | [P | T])       |
   |    Response = SIGN                                |
   |-------------------------------------------------->|
   |                                                   |
   |    4. Server verifies Signature                   |
   |    OCRA(K, [C] | QS | QC | [P|T]) != SIGN -> STOP |
   |    Response = OK                                  |
   |<--------------------------------------------------|
   |                                                   |


 TOC 

8.  Security Considerations

Any algorithm is only as secure as the application and the authentication protocols that implement it. Therefore, this section discusses the critical security requirements that our choice of algorithm imposes on the authentication protocol and validation software.



 TOC 

8.1.  Security Analysis of the OCRA algorithm

The security and strength of this algorithm depends on the properties of the underlying building block HOTP, which is a construction based on HMAC [RFC2104] using SHA-1 as the hash function.

The conclusion of the security analysis detailed in [RFC4226] is that, for all practical purposes, the outputs of the dynamic truncation on distinct counter inputs are uniformly and independently distributed strings.

The analysis demonstrates that the best possible attack against the HOTP function is the brute force attack.



 TOC 

8.2.  Implementation Considerations

IC1 - In the authentication mode, the client MUST support two- factor authentication, i.e., the communication and verification of something you know (secret code such as a Password, Pass phrase, PIN code, etc.) and something you have (token). The secret code is known only to the user and usually entered with the Response value for authentication purpose (two-factor authentication). Alternatively, instead of sending something you know to the server, the client may use a hash of the Password or PIN code in the computation itself, thus implicitly enabling two-factor authentication.

IC2 - Keys should be of the length of the CryptoFunction output to facilitate interoperability.

IC3 - Keys SHOULD be chosen at random or using a cryptographically strong pseudo-random generator properly seeded with a random value. We RECOMMEND following the recommendations in [RFC1750] for all pseudo-random and random generations. The pseudo-random numbers used for generating the keys SHOULD successfully pass the randomness test specified in [CN].

IC4 - Challenge questions SHOULD be 20-byte values and MUST be at least t-byte values where t stands for the digit-length of the OCRA truncation output.

IC5 - On the client side, the keys SHOULD be embedded in a tamper resistant device or securely implemented in a software application. Additionally, by embedding the keys in a hardware device, you also have the advantage of improving the flexibility (mobility) of the authentication system.

IC6 - We RECOMMEND following the recommendations in [RFC1750] for all pseudo-random and random challenge generations.

IC7 - All the communications SHOULD take place over a secure channel e.g. SSL/TLS, IPsec connections.

IC8 - The OCRA algorithm when used in mutual authentication mode or in signature with server authentication mode MAY use dual key mode - i.e. there are two keys that are shared between the client and the server. One shared key is used to generate the server response on the server side and to verify it on the client side. The other key is used to create the response or signature on the client side and to verify it on the server side.

IC9 - We recommend that implementations MAY use the session information, S as an additional input in the computation. For example, S could be the session identifier from the TLS session. This will enable you to counter certain types of man-in-the-middle attacks. However, this will introduce the additional dependency that first of all the prover needs to have access to the session identifier to compute the response and the verifier will need access to the session identifier to verify the response.

IC10 - In the signature mode, whenever the counter or time (defined as optional elements) are not used in the computation, there might be a risk of replay attack and the implementers should carefully consider this issue in the light of their specific application requirements and security guidelines. The server SHOULD also provide whenever possible a mean for the client (if able) to verify the validity of the signature challenge.

IC11 - We also RECOMMEND storing the keys securely in the validation system, and more specifically encrypting them using tamper-resistant hardware encryption and exposing them only when required: for example, the key is decrypted when needed to verify an OCRA response, and re-encrypted immediately to limit exposure in the RAM for a short period of time. The key store MUST be in a secure area, to avoid as much as possible direct attack on the validation system and secrets database. Particularly, access to the key material should be limited to programs and processes required by the validation system only.



 TOC 

9.  IANA Considerations

This document has no actions for IANA.



 TOC 

10.  Conclusion

This draft introduced several variants of HOTP for challenge- response based authentication and short signature-like computations.

The OCRASuite provides for an easy integration and support of different flavors within an authentication and validation system.

Finally, OCRA should enable mutual authentication both in connected and off-line modes, with the support of different response sizes and mode of operations.



 TOC 

11.  Acknowledgements

We would like to thank Jeff Burstein, Shuh Chang, Oanh Hoang, Philip Hoyer, Jon Martinsson, Frederik Mennes, Mingliang Pei, Jonathan Tuliani, Stu Vaeth, Enrique Rodriguez and Robert Zuccherato for their comments and suggestions to improve this draft document.



 TOC 

12.  References



 TOC 

12.1. Normative references

[RFC1750] Eastlake, D., Crocker, S., and J. Schiller, “Randomness Recommendations for Security,” RFC 1750, December 1994.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, “HMAC: Keyed-Hashing for Message Authentication,” RFC 2104, February 1997.
[RFC2119] Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997.
[RFC4226] M'Raihi, D., Bellare, M., Hoornaert, F., Naccache, D., and O. Ranen, “HOTP: An HMAC-Based One-Time Password Algorithm,” RFC 4226, December 2005.


 TOC 

12.2. Informative References

[CN] Coron, J. and D. Naccache, “An accurate evaluation of Maurer's universal test,” LNCS 1556, February 1999.
[OATH] Initiative for Open AuTHentication, “OATH Vision.”


 TOC 

Appendix A.  Reference Implementation



import java.lang.reflect.UndeclaredThrowableException;
import java.security.GeneralSecurityException;
import javax.crypto.Mac;
import javax.crypto.spec.SecretKeySpec;
import java.math.BigInteger;

/**
 * This an example implementation of the OATH OCRA algorithm.
 * Visit www.openauthentication.org for more information.
 *
 * @author Johan Rydell, PortWise
 */
public class OCRA {

    private OCRA() {}

    /**
     * This method uses the JCE to provide the crypto
     * algorithm.
     * HMAC computes a Hashed Message Authentication Code with the
     * crypto hash algorithm as a parameter.
     *
     * @param crypto     the crypto algorithm (HmacSHA1,
     *                   HmacSHA256,
     *                   HmacSHA512)
     * @param keyBytes   the bytes to use for the HMAC key
     * @param text       the message or text to be authenticated.
     */

private static byte[] hmac_sha1(String crypto,
                                byte[] keyBytes,
                                byte[] text)
    {
        try {
            Mac hmac;
            hmac = Mac.getInstance(crypto);
            SecretKeySpec macKey =
                new SecretKeySpec(keyBytes, "RAW");
            hmac.init(macKey);
            return hmac.doFinal(text);
        } catch (GeneralSecurityException gse) {
            throw new UndeclaredThrowableException(gse);
        }
    }


    private static final int[] DIGITS_POWER
    // 0 1  2   3    4     5      6       7        8
    = {1,10,100,1000,10000,100000,1000000,10000000,100000000 };

    /**
     * This method converts HEX string to Byte[]
     *
     * @param hex   the HEX string
     *
     * @return      A byte array
     */
    private static byte[] hexStr2Bytes(String hex){
        // Adding one byte to get the right conversion
        // values starting with "0" can be converted
        byte[] bArray = new BigInteger("10" + hex,16).toByteArray();

        // Copy all the REAL bytes, not the "first"
        byte[] ret = new byte[bArray.length - 1];
        for (int i = 0; i < ret.length ; i++)
            ret[i] = bArray[i+1];
        return ret;
    }


    /**
     * This method generates an OCRA HOTP value for the given
     * set of parameters.
     *
     * @param ocraSuite    the OCRA Suite
     * @param key          the shared secret, HEX encoded
     * @param counter      the counter that changes
     *                     on a per use basis,
     *                     HEX encoded
     * @param question     the challenge question, HEX encoded
     * @param password     a password that can be used,
     *                     HEX encoded
     * @param sessionInformation
     *                     Static information that identifies the
     *                     current session, Hex encoded
     * @param timeStamp    a value that reflects a time
     *
     * @return A numeric String in base 10 that includes
     * {@link truncationDigits} digits
     */
    static public String generateOCRA(String ocraSuite,
            String key,
            String counter,
            String question,
            String password,
            String sessionInformation,
            String timeStamp)
    {
        int codeDigits = 0;
        String crypto = "";
        String result = null;
        int ocraSuiteLength = (ocraSuite.getBytes()).length;
        int counterLength = 0;
        int questionLength = 0;
        int passwordLength = 0;
        int sessionInformationLength = 0;
        int timeStampLength = 0;

        if(ocraSuite.toLowerCase().indexOf("sha1") > 1)
            crypto = "HmacSHA1";
        if(ocraSuite.toLowerCase().indexOf("sha256") > 1)
            crypto = "HmacSHA256";
        if(ocraSuite.toLowerCase().indexOf("sha512") > 1)
            crypto = "HmacSHA512";

        // How many digits should we return
        String oS = ocraSuite.substring(ocraSuite.indexOf(":"),
            ocraSuite.indexOf(":", ocraSuite.indexOf(":") + 1));
        codeDigits = Integer.decode(oS.substring
                                   (oS.lastIndexOf("-")+1,
                                    oS.length()));

        // The size of the byte array message to be encrypted
        // Counter
        if(ocraSuite.toLowerCase().indexOf(":c") > 1) {
            // Fix the length of the HEX string
            while(counter.length() < 16)
                counter = "0" + counter;
            counterLength=8;
        }
        // Question
        if((ocraSuite.toLowerCase().indexOf(":q") > 1) ||
                (ocraSuite.toLowerCase().indexOf("-q") > 1)) {
            while(question.length() < 256)
                question = question + "0";
            questionLength=128;
        }

        // Password
        if((ocraSuite.toLowerCase().indexOf(":p") > 1) ||
                (ocraSuite.toLowerCase().indexOf("-p") > 1)){
            while(password.length() < 40)
                password = "0" + password;
            passwordLength=20;
        }

        // sessionInformation
        if((ocraSuite.toLowerCase().indexOf(":s") > 1) ||
                (ocraSuite.toLowerCase().indexOf("-s",
                 ocraSuite.indexOf(":",
                 ocraSuite.indexOf(":") + 1)) > 1)){
            while(sessionInformation.length() < 128)
                sessionInformation = "0" + sessionInformation;
            sessionInformationLength=64;
        }
        // TimeStamp
        if((ocraSuite.toLowerCase().indexOf(":t") > 1) ||
                (ocraSuite.toLowerCase().indexOf("-t") > 1)){
            while(timeStamp.length() < 16)
                timeStamp = "0" + timeStamp;
            timeStampLength=8;
        }

        // Remember to add "1" for the "00" byte delimiter
        byte[] msg = new byte[ocraSuiteLength +
                              counterLength +
                              questionLength +
                              passwordLength +
                              sessionInformationLength +
                              timeStampLength +
                              1];


        // Put the bytes of "ocraSuite" parameters into the message
        byte[] bArray = ocraSuite.getBytes();
        for(int i = 0; i < bArray.length; i++){
            msg[i] = bArray[i];
        }

        // Delimiter
        msg[bArray.length] = 0x00;

        // Put the bytes of "Counter" to the message
        // Input is HEX encoded
        if(counterLength > 0 ){
            bArray = hexStr2Bytes(counter);
            for (int i = 0; i < bArray.length ; i++) {
                msg[i + ocraSuiteLength + 1] = bArray[i];
            }
        }


        // Put the bytes of "question" to the message
        // Input is text encoded
        if(question.length() > 0 ){
            bArray = hexStr2Bytes(question);
            for (int i = 0; i < bArray.length ; i++) {
                msg[i + ocraSuiteLength + 1 + counterLength] =
                    bArray[i];
            }
        }

        // Put the bytes of "password" to the message
        // Input is HEX encoded
        if(password.length() > 0){
            bArray = hexStr2Bytes(password);
            for (int i = 0; i < bArray.length ; i++) {
                msg[i + ocraSuiteLength + 1 + counterLength
                    + questionLength] = bArray[i];
            }
        }

        // Put the bytes of "sessionInformation" to the message
        // Input is text encoded
        if(sessionInformation.length() > 0 ){
            bArray = hexStr2Bytes(sessionInformation);
            for (int i = 0; i < 128 && i < bArray.length ; i++) {
                msg[i + ocraSuiteLength
                    + 1 + counterLength
                    + questionLength
                    + passwordLength] = bArray[i];
            }
        }

        // Put the bytes of "time" to the message
        // Input is text value of minutes
        if(timeStamp.length() > 0){
            bArray = hexStr2Bytes(timeStamp);
            for (int i = 0; i < 8 && i < bArray.length ; i++) {
                msg[i + ocraSuiteLength + 1 + counterLength +
                questionLength + passwordLength +
                sessionInformationLength] = bArray[i];
            }
        }

        byte[] hash;
        bArray = hexStr2Bytes(key);

        hash = hmac_sha1(crypto, bArray, msg);

        // put selected bytes into result int
        int offset = hash[hash.length - 1] & 0xf;

        int binary =
            ((hash[offset] & 0x7f) << 24) |
            ((hash[offset + 1] & 0xff) << 16) |
            ((hash[offset + 2] & 0xff) << 8) |
            (hash[offset + 3] & 0xff);

        int otp = binary % DIGITS_POWER[codeDigits];

        result = Integer.toString(otp);
        while (result.length() < codeDigits) {
            result = "0" + result;
        }
        return result;
    }
}





 TOC 

Appendix B.  Test Vectors

This section provides test values that can be used for OCRA algorithm interoperability test.

Standard 20Byte key:

3132333435363738393031323334353637383930

Standard 32Byte key:

3132333435363738393031323334353637383930313233343536373839303132

Standard 64Byte key:

31323334353637383930313233343536373839303132333435363738393031323334353637383930313233343536373839303132333435363738393031323334

PIN (1234) SHA1 hash value:

7110eda4d09e062aa5e4a390b0a572ac0d2c0220



 TOC 

B.1.  Plain challenge response



KeyQOCRA Value
Standard 20Byte 00000000 237653
Standard 20Byte 11111111 243178
Standard 20Byte 22222222 653583
Standard 20Byte 33333333 740991
Standard 20Byte 44444444 608993
Standard 20Byte 55555555 388898
Standard 20Byte 66666666 816933
Standard 20Byte 77777777 224598
Standard 20Byte 88888888 750600
Standard 20Byte 99999999 294470

 HOTP-SHA1-6:QN08 



KeyQOCRA Value
Standard 32Byte 00000000 23468859
Standard 32Byte 11111111 30678539
Standard 32Byte 22222222 82867288
Standard 32Byte 33333333 08681556
Standard 32Byte 44444444 21426554

 OCRA-1:HOTP-SHA256-8:QN08-PSHA1 



KeyCQOCRA Value
Standard 32Byte 0 12345678 52663897
Standard 32Byte 1 12345678 72068127
Standard 32Byte 2 12345678 19260949
Standard 32Byte 3 12345678 00504526
Standard 32Byte 4 12345678 18350397

 OCRA-1:HOTP-SHA1-8:C-QD08-PSHA1 



KeyCQOCRA Value
Standard 64Byte 00000 00000000 76837499
Standard 64Byte 00001 11111111 81314151
Standard 64Byte 00002 22222222 12306337
Standard 64Byte 00003 33333333 01404140
Standard 64Byte 00004 44444444 99227510

 OCRA-1:HOTP-SHA512-8:C-QN08 



KeyQTOCRA Value
Standard 64Byte 00000000 132d0b6 87402523
Standard 64Byte 11111111 132d0b6 26305091
Standard 64Byte 22222222 132d0b6 25351647
Standard 64Byte 33333333 132d0b6 87448992
Standard 64Byte 44444444 132d0b6 02480585

 OCRA-1:HOTP-SHA512-8:QN08-T30S 



 TOC 

B.2.  Mutual Challenge Response

OCRASuite (server computation) = OCRA-1:HOTP-SHA256-8:QA08

OCRASuite (client computation) = OCRA-1:HOTP-SHA256-8:QA08



KeyQOCRA Value
Standard 32Byte CLI22220SRV11110 25876570
Standard 32Byte CLI22221SRV11111 68337907
Standard 32Byte CLI22222SRV11112 51935447
Standard 32Byte CLI22223SRV11113 12325872
Standard 32Byte CLI22224SRV11114 50478153

 Server -- OCRA-1:HOTP-SHA256-8:QA08 



KeyQOCRA Value
Standard 32Byte SRV11110CLI22220 65475908
Standard 32Byte SRV11111CLI22221 36352242
Standard 32Byte SRV11112CLI22222 20036871
Standard 32Byte SRV11113CLI22223 58392008
Standard 32Byte SRV11114CLI22224 53668312

 Client -- OCRA-1:HOTP-SHA256-8:QA08 

OCRASuite (server computation) = OCRA-1:HOTP-SHA512-8:QA08

OCRASuite (client computation) = OCRA-1:HOTP-SHA512-8:QA08-PSHA1



KeyQOCRA Value
Standard 64Byte CLI22220SRV11110 22014886
Standard 64Byte CLI22221SRV11111 52086443
Standard 64Byte CLI22222SRV11112 77303083
Standard 64Byte CLI22223SRV11113 39015190
Standard 64Byte CLI22224SRV11114 03327937

 Server -- OCRA-1:HOTP-SHA512-8:QA08 



KeyQOCRA Value
Standard 64Byte SRV11110CLI22220 98411686
Standard 64Byte SRV11111CLI22221 68537161
Standard 64Byte SRV11112CLI22222 70206212
Standard 64Byte SRV11113CLI22223 26271909
Standard 64Byte SRV11114CLI22224 34327256

 Client -- OCRA-1:HOTP-SHA512-8:QA08-PSHA1 



 TOC 

B.3.  Plain Signature

In this mode of operation, Q represents the signature challenge.



KeyQOCRA Value
Standard 32Byte SIG10000 90869451
Standard 32Byte SIG11000 12253571
Standard 32Byte SIG12000 13568297
Standard 32Byte SIG13000 96520389
Standard 32Byte SIG14000 57061117

 OCRA-1:HOTP-SHA256-8:QA08 



KeyQTOCRA Value
Standard 64Byte SIG10000 132d0b6 53166501
Standard 64Byte SIG11000 132d0b6 85946340
Standard 64Byte SIG12000 132d0b6 23754664
Standard 64Byte SIG13000 132d0b6 17883761
Standard 64Byte SIG14000 132d0b6 86963063

  OCRA-1:HOTP-SHA512-8:QA10-T30S 



 TOC 

Authors' Addresses

  David M'Raihi
  Verisign, Inc.
  485 E. Middlefield Road
  Mountain View, CA 94043
  USA
Email:  dmraihi@verisign.com
  
  Johan Rydell
  Portwise, Inc.
  275 Hawthorne Ave, Suite 119
  Palo Alto, CA 94301
  USA
Email:  johan.rydell@portwise.com
  
  Salah Machani
  Diversinet Corp.
  2225 Sheppard Avenue East, Suite 1801
  Toronto, Ontario M2J 5C2
  Canada
Email:  smachani@diversinet.com
  
  David Naccache
  Ecole Normale Superieure
  ENS DI, 45 rue d'Ulm
  Paris, 75005
  France
Email:  david.naccache@ens.fr
  
  Siddarth Bajaj
  Verisign, Inc.
  485 E. Middlefield Road
  Mountain View, CA 94043
  USA
Email:  sbajaj@verisign.com