# Patent application title: SYSTEM AND METHOD OF PERFORMING AUTHENTICATION

##
Inventors:
Mathieu Ciet (Paris, FR)
Augustin Farrugia (Cupertino, CA, US)
Jean-Francois Riendeau (Santa Clara, CA, US)
Nicholas T. Sullivan (Sunnyvale, CA, US)
Nicholas T. Sullivan (Sunnyvale, CA, US)

Assignees:
Apple Inc.

IPC8 Class: AH04L900FI

USPC Class:
380277

Class name: Cryptography key management

Publication date: 2011-12-29

Patent application number: 20110317840

## Abstract:

Disclosed herein are systems, method and computer readable medium for
providing authentication of an entity B by an entity A. In the method,
entity A selects a value p, a range [a, b] and a granularity epsilon.
Entity A sends p, [a, b], and epsilon to entity B. Entity B initializes a
value y_{B}=0 and for each x in {a, a+epsilon, . . . , b-epsilon, b} and computes z=E(x)*x. The function E(x) is an encryption scheme and the multiplication is carried out mod p. Entity B updates y

_{B}=y

_{B}+z. After processing each x, entity B sends y

_{B}to entity A. Entity A performs the same calculation and generates a y

_{A}value and compares y

_{A}with y

_{B}. If y

_{B}=y

_{A}, Entity A authenticate entity B. In one aspect, a light HMAC scheme splits an input x into n blocks with key expansion.

## Claims:

**1.**A method comprising: splitting an input x into n number of x

_{i}blocks; initializing an input key RK[0]=k; initializing y=0; performing key expansion by, for each p in {1 . . . L-1}, computing round keys as RK[p]=R(RK[p-1]); generating an updated y as follows: for each i in {0 . . . (n-1)}: setting y=y XOR x

_{i}; for each j in {0 . . . L-1}: computing y=R(y); and setting y=y XOR RK[j]; setting y=R(y); and outputting y for use in authentication.

**2.**The method of claim 1, wherein performing key expansion further comprises, for each round key: performing a function g

_{i}that performs steps comprising: receiving a first set of bits and outputs a second set of bits; and processing the first set of bits by concatenating members of the first set and XORing the concatenation with a constant, and (3) generates an output from g

_{i}; performing a function G

_{i}that performs steps comprising: compressing the output from g

_{i}; and generating compressed output from G

_{i}; and exclusive or'ing the compressed output from G

_{i}with the first set of bits to generate a respective round key.

**3.**The method of claim 2, wherein g

_{i}comprises: g

_{i}(x

_{0},x

_{1},c)=(((x.sub.

**0.**parallel.x

_{1}+c)

^{2}XOR cst

_{i}XOR(((x.sub.

**0.**parallel.x

_{1}+c)>>16)

^{2})mod

**2.**sup.

**32.**

**4.**The method of claim 3, wherein G

_{i}comprises: G

_{i}(x

_{0},x

_{1},x

_{2},x

_{3},c)=[(((x.sub.

**0.**parallel.x

_{1}+c- )

^{2}XOR csti

_{i}XOR(((x.sub.

**0.**parallel.x

_{1}+c)

^{2}>>32))+(((x.sub.

**2.**parallel.x-

_{3})+c)

^{2}XOR csti

_{i}XOR((x.sub.

**2.**parallel.x

_{3})+c)

^{2}>>32))] mod

**2.**sup.

**32.**

**5.**The method of claim 4, wherein cst

_{i}and csti

_{i}are constant values depending on i, and wherein each x

_{i}comprises 2 bytes of data.

**6.**A method comprising: initializing an input key RK[0]=k; initializing y=0; performing key expansion by generating a table of round keys for a pre-determined number of rounds L, wherein the key expansion function comprises, for each round key: performing a function g

_{i}that concatenates members of a first set of bits and XORs the concatenated members with a constant to generate a second set of bits; performing a function G

_{i}that compresses the second set of bits from g

_{i}and generates compressed output; and exclusive or'ing the compressed output with the first set of bits to generate a respective round key; generating an updated y by using the table of round keys in an iterative application of an encryption scheme; and storing y for use in authentication.

**7.**The method of claim 6, wherein multiple iterations of the function g

_{i}occur with each round.

**8.**The method of claim 6, wherein g

_{i}comprises: g

_{i}(x

_{0},x

_{1},c)=(((x.sub.

**0.**parallel.x

_{1}+c)

^{2}XOR cst

_{i}XOR(((x.sub.

**0.**parallel.x

_{1}+c)>>16)

^{2})mod

**2.**sup.

**32.**

**9.**The method of claim 8, wherein G

_{i}comprises: G

_{i}(x

_{0},x

_{1},x

_{2},x

_{3},c)=[(((x.sub.

**0.**parallel.x

_{1}+c- )

^{2}XOR csti

_{i}XOR(((x.sub.

**0.**parallel.x

_{1}+c)

^{2}>>32))+(((x.sub.

**2.**parallel.x-

_{3})+c)

^{2}XOR csti

_{i}XOR((x.sub.

**2.**parallel.x

_{3})+c)

^{2}>>32))] mod

**2.**sup.

**32.**

**10.**A system comprising: a processor; a memory storing instructions for controlling the processor to perform steps comprising: receiving an input x that comprises a set of x

_{i}blocks; performing key expansion by, for i=1 to L-1, computing round keys as RK[i]=R(RK[i-1]), wherein RK[0] is an input key having a value k; generating an updated y as follows: for i=0 to (n-1): setting y=y XOR x

_{i}wherein y has an initial value of 0; for j=0 to L-1: computing y=R(y); and setting y=y XOR RK[j]; setting y=R(y); and outputting y for use in authentication.

**11.**The system of claim 10, wherein performing key expansion further comprises, for each round key: performing a function g

_{i}that (1) receives a first set of bits and outputs a second set of bits, (2) processes the first set of bits by concatenating members of the first set and XORing the concatenation with a constant, and (3) generates an output from g

_{i}; performing a function G

_{i}that compresses the output from g

_{i}and generates compressed output from G

_{i}; and XORing the compressed output from G

_{i}with the first set of bits to generate a respective round key.

**12.**The system of claim 11, wherein g

_{i}comprises: g

_{i}(x

_{0},x

_{1},c)=(((x.sub.

**0.**parallel.x

_{1}+c)

^{2}XOR cst

_{i}XOR(((x.sub.

**0.**parallel.x

_{1}+c)>>16)

^{2})mod

**2.**sup.

**32.**

**13.**The system of claim 12, wherein G

_{i}comprises: G

_{i}(x

_{0},x

_{1},x

_{2},x

_{3},c)=[(((x.sub.

**0.**parallel.x

_{1}+c- )

^{2}XOR csti

_{i}XOR(((x.sub.

**0.**parallel.x

_{1}+c)

^{2}>>32))+(((x.sub.

**2.**parallel.x-

_{3})+c)

^{2}XOR csti

_{i}XOR((x.sub.

**2.**parallel.x

_{3})+c)

^{2}>>32))] mod

**2.**sup.

**32.**

**14.**The system of claim 13, wherein cst

_{i}and csti

_{i}are constant values depending on i, and wherein each x

_{i}comprises 2 bytes of data.

**15.**A system comprising: a processor; a memory storing instructions for controlling the processor to perform steps comprising: performing key expansion on an input key by generating a table of round keys for a pre-determined number of rounds L, wherein the key expansion function comprises, for each round key: performing a function g

_{i}that concatenates members of a first set of bits and exclusive or's the members with a constant to generate a second set of bits; performing a function G

_{i}that compresses the second set of bits from g

_{i}to yield compressed output; and exclusive or'ing the compressed output with the first set of bits to generate a respective round key; generating an updated output value by using the table of round keys in an iterative application of an encryption scheme; and storing the updated output value in an authentication database.

**16.**The system of claim 15, wherein multiple iterations of the function g

_{i}occur with each round.

**17.**The system of claim 15, wherein g

_{i}comprises: g

_{i}(x

_{0},x

_{1},c)=(((x.sub.

**0.**parallel.x

_{1}+c)

^{2}XOR cst

_{i}XOR(((x.sub.

**0.**parallel.x

_{1}+c)>>16)

^{2})mod

**2.**sup.

**32.**

**18.**The system of claim 17, wherein G

_{i}comprises: G

_{i}(x

_{0},x

_{1},x

_{2},x

_{3},c)=[(((x.sub.

**0.**parallel.x

_{1}+c- )

^{2}XOR csti

_{i}XOR(((x.sub.

**0.**parallel.x

_{1}+c)

^{2}>>32))+(((x.sub.

**2.**parallel.x-

_{3})+c)

^{2}XOR csti

_{i}XOR((x.sub.

**2.**parallel.x

_{3})+c)

^{2}>>32))] mod

**2.**sup.

**32.**

**19.**A non-transitory computer-readable storage medium storing instructions which, when executed by a computing device, cause the computing device to perform steps comprising: receiving an input x having x

_{i}blocks; performing key expansion by computing, for i=1 to L-1, iteration keys as RK[i]=R(RK[i-1]), wherein RK[0] is an input key having a value k; generating an updated y as follows: for i=0 to (n-1): setting y=y XOR x

_{i}, wherein y has an initial value of 0; for j=0 to L-1: computing y=R(y); and setting y=y XOR RK[j]; setting y=R(y); and storing y in an authentication database.

**20.**The non-transitory computer-readable storage medium of claim 19, wherein performing key expansion further comprises, for each iteration key: performing a function g

_{i}that (1) receives a first set of bits and outputs a second set of bits, (2) processes the first set of bits by concatenating members of the first set and XORing the concatenation with a constant, and (3) generates an output from g

_{i}; performing a function G

_{i}that compresses the output from g

_{i}and generates compressed output from G

_{i}; and XORing the compressed output from G

_{i}with the first set of bits to generate a respective iteration key.

**21.**The non-transitory computer-readable storage medium of claim 20, wherein g

_{i}comprises: g

_{i}(x

_{0},x

_{1},c)=(((x.sub.

**0.**parallel.x

_{1}+c)

^{2}XOR cst

_{i}XOR(((x.sub.

**0.**parallel.x

_{1}+c)>>16)

^{2})mod

**2.**sup.

**32.**

**22.**The non-transitory computer-readable storage medium of claim 21, wherein G

_{i}comprises: G

_{i}(x

_{0},x

_{1},x

_{2},x

_{3},c)=[(((x.sub.

**0.**parallel.x

_{1}+c- )

^{2}XOR csti

_{i}XOR(((x.sub.

**0.**parallel.x

_{1}+c)

^{2}>>32))+(((x.sub.

**2.**parallel.x-

_{3})+c)

^{2}XOR csti

_{i}XOR((x.sub.

**2.**parallel.x

_{3})+c)

^{2}>>32))] mod

**2.**sup.

**32.**

**23.**A non-transitory computer-readable storage medium storing instructions which, when executed by a computing device, cause the computing device to perform steps comprising: performing key expansion on an input key by generating a table of iteration keys for L iterations, wherein the key expansion comprises, for each iteration key: concatenating a first set of bits and exclusive or'ing the first set of bits with a constant to generate a second set of bits; compressing the second set of bits to yield compressed bits; and exclusive or'ing the compressed bits with the first set of bits to generate a respective iteration key; generating an updated output value by iteratively applying the table of iteration keys in an encryption scheme; and storing the updated output value in an authentication database.

**24.**The non-transitory computer-readable storage medium of claim 23, wherein multiple iterations of concatenating the first set of bits occur with each iteration.

**25.**The non-transitory computer-readable storage medium of claim 24, wherein exclusive or'ing the first set of bits comprises: g

_{i}(x

_{0},x

_{1},c)=(((x.sub.

**0.**parallel.x

_{1}+c)

^{2}XOR cst

_{i}XOR(((x.sub.

**0.**parallel.x

_{1}+c)>>16)

^{2})mod

**2.**sup.

**32.**

## Description:

**CROSS**-REFERENCE TO RELATED APPLICATIONS

**[0001]**This application is a divisional of U.S. patent application Ser. No. 12/116,819, filed on May 7, 2008, which is incorporated by reference in its entirety, for all purposes, herein.

**BACKGROUND OF THE INVENTION**

**[0002]**1. Field of the Invention

**[0003]**The present invention relates to authentication and more specifically relates to a system and method of providing authentication based on a weighted average principal.

**[0004]**2. Introduction

**[0005]**Protection of digital content transferred between entities over a network is a principal element of computer security. Computer security includes protection of digital content from theft or corruption and also addresses the preservation of system availability. Authentication plays an important role in computer security. Authentication is the process of verifying the digital identity of the sender of a communication. Once an entity has been authenticated, data transfer between the two entities may begin.

**[0006]**Authentication systems provide differing levels of functionality. At a minimum, they allow a recipient to verify that a message originated from a particular user, program or computer. More powerful systems can ensure that messages cannot be copied and replayed in the future, prove to a third party that a message originated with a particular user (non-repudiation), or require multiple users to validate a message.

**[0007]**Authentication is often used in conjunction with cryptography. Cryptography is the traditional method of protecting data. Cryptography protects communications between two mutually trusting parties from thievery or hackers by attack on the data in transit. Encryption is the process of obscuring information in a systematic way, using an algorithm. Decryption is process of removing the protection and retrieving the original data. Encryption and decryption use a key, which is the shared secret that both parties must have. To ensure data integrity, only the authorized parties should hold the secret key.

**[0008]**In many communication systems, the weakest link in security is not the encrypted data but rather cryptographic key management and handling. Unauthorized users may gain access to sensitive data when key management is not performed securely.

**[0009]**Many processes for authenticating an entity have been proposed. Typically, a sender sends a message and both the sender and receiver use the message and a shared secret key to generate a signature. If the signatures are the same, the entity is accepted as authentic in a symmetric encryption scheme. If an asymmetric scheme is used, the system verifies the signature is valid since only the originator of the signature should be able to create that signature.

**[0010]**A system can be compromised when patterns in the signature can be detected and used to surmise and exploit the authentication process. Attacking such encryption schemes requires the collection of a set of the input and the output. Typically, encryption schemes are used to authenticate by encrypting a value. If both the sender and receiver generate the same value, authentication is achieved. What is needed in the art, however, is an improved authentication process that is less susceptible to hacking.

**SUMMARY**

**[0011]**Additional features and advantages of the invention will be set forth in the description which follows, and in part will be obvious from the description, or may be learned by practice of the invention. The features and advantages of the invention may be realized and obtained by means of the instruments and combinations particularly pointed out in the appended claims. These and other features of the present invention will become more fully apparent from the following description and appended claims, or may be learned by the practice of the invention as set forth herein.

**[0012]**Disclosed herein are systems, method and computer readable media related to authentication. In order to address the possible attacks on an encryption scheme by collecting a set of the input and output, an aspect of the present disclosure renders it more difficult to collect such input and output values since generating those values involves a more complicated process. In one exemplary embodiment enables an entity A to authenticate an entity B. The method includes, at entity A: selecting a value p, a range [a, b] and a granularity epsilon. The value p is preferably a power of 2 but may depend on other powers as well. Entity A sends p, the range [a, b] and the granularity epsilon to an entity B. At entity B, the method includes initializing y

_{B}=0 and for each x in a set {a, a+epsilon, . . . , b-epsilon, b}, performing the following steps: computing z=E(x)*x, wherein E(x) is an encryption scheme (the multiplication is carried out mod p), and updating y

_{B}=y

_{B}+z. In one embodiment, the E(x) is the proposed HMAC scheme disclosed herein. Entity B then transmits y

_{B}to entity A. Entity A then uses the same calculation to generate a y

_{A}value. The value y

_{A}is compared with the value y

_{B}and if they are determined to be equal, entity A accepts entity B as authentic.

**[0013]**In a variation on the method set forth above, entity B may not receive the granularity epsilon but may generate the value and then perform similar steps as set forth above using the locally generated granularity epsilon. The basis upon which entity B generates the granularity epsilon may vary. The granularity epsilon may be predetermined instead of generated.

**[0014]**The principle discussed above regarding sending or sharing a set {a

_{i}} may be extended using a polynomial principle. In the "polynomial principle" aspect of the disclosed scheme, P is the result calculated by both parties. Here, let P equal a sum a

_{i}*x

^{i}over i. The values of the set {x

_{i}} are sent from entity A to entity as above. The set of values {a

_{i}} is preferably defined a priori and communicated to each of entity A and entity B. The value P, the sum a

_{i}*x

^{i}over i (for each x in the set), may be transmitted from entity A or calculated locally at entity B. In this case, the value of P represents either y

_{A}or y

_{B}depending on what entity performed the calculation. Under this approach, no encryption may be performed in the authentication process.

**[0015]**We next return to the scenario where encryption is used. Entity A sends a set of values {x

_{i}} and the value p to entity B. Entity B computes a result based on the set {a

_{i}} and E(x

_{i}), wherein E(x

_{i}) represents an encryption scheme or a hash MAC scheme and multiplication is carried out mod p. A value y

_{B}is set to equal the calculated result and entity B transmits y

_{B}to entity A. Entity A performs the same computation to calculate a y

_{A}value which is compared with the generated y

_{B}to determine whether to accept entity B as authentic.

**[0016]**Because of the increased security gained by using the improved key management scheme above, a classical encryption scheme or a less secure encryption scheme may be used without a reduction in overall security. Another embodiment of this disclosure proposes a new "light" hash message authentication code (HMAC) scheme which can be viewed as a less secure approach that can be used in connection with the improved authentication process disclosed herein. The disclosed "light" HMAC scheme may also stand independent of the particular authentication scheme as a separate embodiment.

**[0017]**The HMAC is a type of message authentication code that is calculated using a specific algorithm involving a cryptographic hash function in combination with a secret key. For further background information on HMAC, see the publication of the specifications for The Keyed-Hash Message Authentication Code (HMAC), 2002 Mar. 6, Federal Information Processing Standards Publication 198, incorporated herein by reference. This embodiment provides an alternate approach in which an HMAC is created based on an encryption scheme. A component of the light HMAC scheme is the implementation of a function R as disclosed herein. In this aspect, the method includes splitting an input x into n number of x

_{i}blocks, initializing an input key RK[0]=k and initializing y=0. The method includes performing key expansion by, for i=1 to L, computing round keys as RK[i]=R(RK[i-1]). An updated y is generated as follows: for i=0 to (n-1), setting y=y XOR xi. For j=0 to L-1: computing y=R(y) and setting y=y XOR RK[j] and setting y=R(y). The computed value of y is output and used for in authentication.

**[0018]**Steps that may be involved in the key expansion process include performing a function g

_{i}that concatenates members of a first set of bits and XORs the concatenated members with a constant to generate a second set of bits, performing a function Gi that compresses the second set of bits from g

_{i}and generates a compressed output and XORing the compressed output with the first set of bits to generate a respective round key. Multiple iterative application of the function g

_{i}can be performed.

**[0019]**Other aspects of the disclosure as found herein also include a black box approach in which a particular embodiment involves processing as viewed by an entity A or an entity B separately.

**BRIEF DESCRIPTION OF THE DRAWINGS**

**[0020]**In order to describe the manner in which the above-recited and other advantages and features of the invention can be obtained, a more particular description of the invention briefly described above will be rendered by reference to specific embodiments thereof which are illustrated in the appended drawings. Understanding that these drawings depict only exemplary embodiments of the invention and are not therefore to be considered to be limiting of its scope, the invention will be described and explained with additional specificity and detail through the use of the accompanying drawings in which:

**[0021]**FIG. 1 illustrates a basic system embodiment of the invention;

**[0022]**FIG. 2 illustrates a prior art approach using a message authentication code;

**[0023]**FIG. 3 illustrates basic example processing and communication between an entity A and an entity B;

**[0024]**FIG. 4A illustrates a method embodiment;

**[0025]**FIG. 4B illustrates a method embodiment;

**[0026]**FIG. 4C illustrates yet another method embodiment;

**[0027]**FIG. 4D illustrates yet another method embodiment;

**[0028]**FIGS. 5A and 5B illustrate various algorithms used in a process of key expansion;

**[0029]**FIG. 5C graphically illustrates a process of generating round keys according to an aspect of the disclosure;

**[0030]**FIG. 5D illustrates a flow diagram of the more detailed diagram of FIG. 5C;

**[0031]**FIG. 6 illustrates yet another method embodiment related to a light HMAC scheme; and

**[0032]**FIG. 7 illustrates an example flow diagram of an algorithm according to the light HMAC scheme.

**DETAILED DESCRIPTION**

**[0033]**Various embodiments of the invention are discussed in detail below. While specific implementations are discussed, it should be understood that this is done for illustration purposes only. A person skilled in the relevant art will recognize that other components and configurations may be used without parting from the spirit and scope of the invention.

**[0034]**With reference to FIG. 1, an exemplary system includes a general-purpose computing device 100, including a processing unit (CPU) 120 and a system bus 110 that couples various system components including the system memory such as read only memory (ROM) 140 and random access memory (RAM) 150 to the processing unit 120. Other system memory 130 may be available for use as well. It can be appreciated that the invention may operate on a computing device with more than one CPU 120 or on a group or cluster of computing devices networked together. The system bus 110 may be any of several types of bus structures including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures. A basic input/output (BIOS) stored in ROM 140 or the like, may provide the basic routine that helps to transfer information between elements within the computing device 100, such as during start-up. The computing device 100 further includes storage devices such as a hard disk drive 160, a magnetic disk drive, an optical disk drive, tape drive or the like. The storage device 160 is connected to the system bus 110 by a drive interface. The drives and the associated computer readable media provide nonvolatile storage of computer readable instructions, data structures, program modules and other data for the computing device 100. The basic components are known to those of skill in the art and appropriate variations are contemplated depending on the type of device, such as whether the device is a small, handheld computing device, a desktop computer, a phone or a computer server.

**[0035]**Although the exemplary environment described herein employs the hard disk, it should be appreciated by those skilled in the art that other types of computer readable media which can store data that are accessible by a computer, such as magnetic cassettes, flash memory cards, digital versatile disks, cartridges, random access memories (RAMs), read only memory (ROM), a cable or wireless signal containing a bit stream and the like, may also be used in the exemplary operating environment.

**[0036]**To enable user interaction with the computing device 100, an input device 190 represents any number of input mechanisms, such as a microphone for speech, a touch-sensitive screen for gesture or graphical input, keyboard, mouse, motion input, speech and so forth. The device output 170 can also be one or more of a number of output mechanisms known to those of skill in the art. In some instances, multimodal systems enable a user to provide multiple types of input to communicate with the computing device 100. The communications interface 180 generally governs and manages the user input and system output. There is no restriction on the invention operating on any particular hardware arrangement and therefore the basic features here may easily be substituted for improved hardware or firmware arrangements as they are developed.

**[0037]**For clarity of explanation, the illustrative system embodiment is presented as comprising individual functional blocks (including functional blocks labeled as a "processor"). The functions these blocks represent may be provided through the use of either shared or dedicated hardware, including, but not limited to, hardware capable of executing software. For example the functions of one or more processors presented in FIG. 1 may be provided by a single shared processor or multiple processors. (Use of the term "processor" should not be construed to refer exclusively to hardware capable of executing software.) Illustrative embodiments may comprise microprocessor and/or digital signal processor (DSP) hardware, read-only memory (ROM) for storing software performing the operations discussed below, and random access memory (RAM) for storing results. Very large scale integration (VLSI) hardware embodiments, as well as custom VLSI circuitry in combination with a general purpose DSP circuit, may also be provided. The fundamentality of software components programmed to control or utilize hardware components such as a processor and a display may be termed modules that are configured to perform any of the functionality disclosed herein. Such modules are considered hardware components in that they require functionality that is connected to or controlling at least one hardware component.

**[0038]**FIG. 2 illustrates a prior art cryptographic method authentication code (MAC). This is simply a shorten piece of information that is used to authenticate a message. As shown, an environment 200 involving an entity A has a message 202a that is to be delivered to entity B. Entity B receives the message 202b and needs to authenticate the message. Entity A utilizes a key k that is used to perform a MAC algorithm 204 that generates the MAC code 206. The message and the MAC are transmitted to entity B. Entity B receives the message and utilizes the same key k to process the message through a similar MAC algorithm 204 to generate MAC 208. An authentication mechanism 210 determines if MAC 206 equals MAC 208. If so, authentication is confirmed.

**[0039]**Disclosed herein is an authentication function that is generally based on a weighted average principle. The disclosure herein may be used as a modification of a classical encryption scheme using something similar to a weighted area defined by a curve from any classical algorithm. FIG. 3 illustrates a general arrangement 300 according to the disclosure. As is mentioned above relative to FIG. 2, a cryptographic message authentication code (MAC) is a piece of information that may be used to authenticate a message. For example, using the diagram shown in FIG. 2, a prior art approach would be to utilize an encryption scheme 204 that works on data in a range R=[0, . . . , 2.sup.(L-1)]. The range of input is understood to be the same as the range of output. In other words, R is a defined as a bijection having the certain property that for each x in a set X, there is a function f(x) that maps to a value y in the set Y. With this understanding of the range of input, encryption schemes are typically used to authenticate by encrypting a challenge. Once the encryption is calculated on a receiving side, the receiving system determines if the encrypted value matches the value sent by the sender. A match proves that the key k is available on both sides where the encryption has been done, but the key has not been revealed. It is easier for a hacker to break one encryption than the proposed multiple encryption approach.

**[0040]**The present invention addresses the issue of a need for an improved authentication and key management approach. This disclosure addresses the possible attacks on an encryption scheme by collecting a set of the input and output. The proposed scheme renders it more difficult to collect such input and output values since generating these values involves a more complicated process. Rather than doing only one encryption, the present invention defines a scheme where entity A needs to authenticate B and where an iterative process is applied. FIG. 3 illustrates an environment 300 in which entity A and entity B communicate via a network 302. The network may be the internet, a LAN, a wireless network, or any other type of communication network known or hereinafter developed. In this example, entity A needs to authenticate entity B. The authentication may relate to a value that is used to define the device used by entity B, a person, a message, and so forth. In other words, the authentication may relate to any number of particular entities which are desirable to authenticate. FIG. 3 will also be discussed in connection with the method disclosed in FIG. 4A.

**[0041]**In this example, entity A performs several functions. In block 304, entity A selects a value p, which is preferably a power of 2 but may be other values as well, selects a range [a, b] and a granularity epsilon (402). The granularity epsilon is used to define at entity B what values in the range [a, b] will be used in its calculations. For example, if the range is [0, 10] and the granularity epsilon is 2, then the values used at entity B will be 0, 2, 4, 6, 8, 10. Entity A transmits p, the range [a, b] and the granularity epsilon to entity B (404). Next, entity B performs multiple encryptions. Here, as shown in block 308, entity B initializes y

_{B}as 0 (406) and for each x in the set {a, a+epsilon, . . . , b-epsilon, b} (408), entity B computes z=E(x)*x, wherein E(x) is an encryption scheme or an HMAC scheme and the multiplication is carried out mod p. In one aspect, E(x) is the "light" HMAC scheme disclosed herein. Entity B updates y

_{B}=y

_{B}+z (410). After iterating through each x in the set (412), entity B transmits y

_{B}from entity B to entity A (414). The value Y

_{B}is stored in one or more locations and is used for authentication (416). In one aspect, the range and the granularity epsilon may be relatively small.

**[0042]**One mechanism by which y

_{B}may be used in authentication is wherein entity A calculates a y

_{A}value by initializing y

_{A}=0 and for each x in {a, a+epsilon, . . . , b-epsilon, b}, computing z=E(x)*x, wherein E(x) is an encryption scheme or a hashing mac scheme (the multiplication is carried out mod p), and updates y

_{A}=y

_{A}+z. After iteratively following through the process for each x in the set, a y

_{A}is generated that is then compared to the y

_{B}for authentication. This approach provides a more complex authentication process wherein rather than doing a single encryption calculation, multiple encryption calculations are performed to generate y value used for authentication. Ultimately, if y

_{B}=y

_{A}, entity B is accepted as authentic. Under the principles disclosed herein, the encryption scheme may be any encryption scheme such as the known AES, DES, or HMAC. Any other encryption scheme may be used in the authentication process.

**[0043]**FIG. 4B illustrates an alternate embodiment also which will be discussed in connection with FIG. 3. Here, entity A selects a value p and a range [a,b] (420) and sends p and the range [a, b] to entity B (422). The difference in this embodiment from the previous embodiment is that entity B selects a granularity epsilon (424). In one aspect, the granularity epsilon in this embodiment as well as in the previous embodiment may be a constant like the number 2. Entity B may select the granularity based on a property associated with the range [a, b]. For example, the granularity epsilon may be selected based on how large the range is relative to some other value. The granularity epsilon may be selected to be large or small relative to the provided range. The granularity epsilon may be selected based on a requirement that the E(x) for any x is uniformly distributed over the range [a, b]. For example, a random x may be selected from the range and an evaluation of E(x) may be performed. The resulting granularity epsilon may be selected based on the evaluation.

**[0044]**In another aspect, the granularity epsilon can be selected by an equation or be used in connection with an equation. These equations can be used to render the selection of values x from the range [a, b] more complex or dynamic. Furthermore, entity B may select a granularity epsilon or implement an equation based on some other factor such as a coordinated time or some other physical value that may be retrieved independently from entity A and entity B. These variations could provide increased security in the authentication process.

**[0045]**Next, entity B initializes y

_{B}as 0 (426) and for each x in {a, a+epsilon, . . . , b-epsilon, b} (428). The value y

_{B}may be initialized to any other value as well besides zero. Entity B computes z=E(x)*x, wherein E(x) is an encryption scheme (the multiplication is carried out mod p), and updates y

_{B}=y

_{B}+z (430). The method then determines whether there is another x in the range [a, b] (432) and if so, proceeds to step (430) for processing another iteration in the loop. If the loop has processed each x in the range [a, b], then the method includes sending y

_{B}from entity B to entity A (434) and storing y

_{B}for use in authentication (436).

**[0046]**The method may also include comparing y

_{B}with a y

_{A}generated when entity A performs the same calculation disclosed above. If y

_{B}=y

_{A}, then the system accepts entity B as authentic. Also as noted above, p is preferably a power of 2 that may be some other value as well. Also as noted above, the encryption scheme used in step (430) may be one of AES, DES, HMAC, a hashing function, the "light" HMAC scheme below or some other known or hereinafter developed encryption scheme.

**[0047]**Another aspect related to FIG. 3 involves defining a set of values {a

_{i}} and P as a polynomial representing a sum of a

_{i}*x

_{i}

^{i}over i, where x

_{i}

^{i}means x

_{i}to the power of i. The values {a

_{i}} represent the coefficients in the polynomial. As noted above, this P may be used as an alternative y

_{A}, y

_{B}pair. The set of values {a

_{i}} is provided to each entity A and entity B. Entity A sends entity B a defined set of values {x

_{i}} and preferably a p value. The set of values {a

_{i}} may be a random set or any other determined set. Entity B computes a result based on the set {a

_{i}} and E(x

_{i}), wherein E(x

_{i}) represents an encryption scheme and the multiplication is carried out mod p. For example, the solution involves computing a

_{0}*E(x

_{0})+a

_{1}*E(x

_{1})+a

_{2}*x

_{2}

^{2}*E(x

_{2})+ . . . . The computed result is set equal to y

_{B}and transmitted from entity B to entity A wherein it is stored for use in authentication.

**[0048]**Entity A then generates a y

_{A}by performing the same computation used to generate y

_{B}. If y

_{B}equals y

_{A}, then entity A accepts entity B as authentic. As discussed above, any encryption or hashing function may be used in the authentication process. The computation of a result based on the set {a

_{i}} and E(x

_{i}) may include a sum of a

_{i}*x

_{i}

^{i}*E(x

_{i}) over each value of i or a sum of a

_{i}*(x

_{i}*E(x

_{i}))

^{i}over i. An advantage of this approach is that it can protect the encryption scheme E since an attacker does not have the ability to choose the input. This is referred to as a chosen plaintext attack, and this approach renders it harder to break the scheme. Note that in the generalization approaches above related to the use of polynomials, the granularity is predetermined inasmuch as it depends on the number of coefficients. As an example, the solution to this embodiment is a

_{0}+a

_{1}*x

_{1}*E(x

_{1})+a

_{2}*(x

_{2}*E(x

_{2}))

^{2}+ . . . . The disclosed approach can be used with any classical encryption scheme and can also be used with an HMAC function. Another advantage of the disclosure is that it possible to use a less secure encryption scheme, such as the "light" HMAC scheme disclosed below.

**[0049]**Because of the increased level of security provided in key management as set forth above, a simpler encryption scheme may be applied and maintain the same or better overall level of security. Accordingly, another embodiment of this disclosure discussed next relates to a version of the HMAC function which may be referred to as a "light" HMAC scheme because it is easy to implement and efficient. There are only two basic functions which can be implemented directly or using different approach such as digital signal processing.

**[0050]**First, a function g

_{i}is defined as follows:

**g**

_{i}(x

_{0},x

_{1},c)=(((x

_{0}∥x

_{1}+c)

^{2}XOR cst

_{i}XOR(((x

_{0}∥x

_{1}+c)>>16)

^{2})mod 2

^{32}.

**[0051]**Here, "∥" denotes the concatenation operation. Each x

_{i}is preferably 2 bytes but may be represented by a different number of bits as well. Let G

_{i}be defined as:

**G**

_{i}(x

_{0},x

_{1},x

_{2},x

_{3},c)=[(((x

_{0}∥x

_{1}+- c)

^{2}XOR csti

_{i}XOR(((x

_{0}∥x

_{1}+c)

^{2}>>32))+(((x

_{2}∥x-

_{3})+c)

^{2}XOR csti

_{i}XOR((x

_{2}∥x

_{3})+c)

^{2}>>32))] mod 2

^{32}.

**[0052]**When x

_{i}is 2 bytes, the input to g

_{i}is 32 bits in length and the output is 32 bits in length. The input to G

_{i}is 64 bits in length and the output is 32 bits in length, thus providing a compression of the data. The values c, cst

_{i}and csti

_{i}are constant values depending on i. These values are typically stored in a table. The light HMAC scheme disclosed herein is an iterative scheme. One internal round during the key expansion phase of the light HMAC scheme generates output data based on the input data for a particular x. The output is the concatenation x

_{0}∥x

_{1}∥x

_{2}∥x

_{3}∥x.sub- .4∥x

_{5}∥x

_{6}∥x

_{7}, which in this example is 128 bits. Also, it is noted that the general principles of this scheme may be applicable to other organizations of input data. For example, the bit value of x, split into n number of x

_{i}blocks may also be processed wherein x is a greater or lesser number of bits and n is more or less than eight.

**[0053]**Another aspect of the disclosure relates to a method of authentication that is centric to a particular entity. This is shown in FIG. 4C. In this embodiment, the method is viewed as being performed only in view of entity A or entity B. For the embodiment related to entity A, the method includes, at entity A, selecting a value p, a range [a, b] and a granularity epsilon (440). Entity A sends p, the range [a, b] and the granularity epsilon to an entity B (442). Entity B performs its processing and generates a value y

_{B}. Entity A receives y

_{B}from entity B (446) and stores this value for use in authentication (448). The value y

_{B}will be compared to a value y

_{A}that is generated according to a process which involves initializing a y

_{A}value at 0, and for each x in {a, a+epsilon, . . . , b-epsilon, b}, computing z=E(x)*x, wherein E(x) is an encryption scheme (the multiplication is carried out mod p) and updating y

_{A}=y

_{A}+z. Entity B performs the same operations in generating y

_{B}. Here, entity B initializes y

_{B}=0, for each x in {a, a+epsilon, . . . , b-epsilon, b} and computes z=E(x)*x. The function E(x) is an encryption scheme and the multiplication is carried out mod p. Entity B then updates y

_{B}=y

_{B}+z (446). Therefore, each of entity A and entity B performs the identical calculation, but this embodiment is viewed from the perspective at entity A.

**[0054]**Similarly, another embodiment of the disclosure relates to processing as viewed from entity B. This aspect is illustrated in FIG. 4D. Here, the method of authentication utilizes a predetermined set of values {a

_{i}} and a value P defined as the sum of a

_{i}*x

_{i}

^{i}over i, wherein x

_{i}

^{i}is x

_{i}to the power of i. The method comprises, at a receiver, receiving a set of values {x

_{i}} and P from a sender (450). The receiver generates a computation result based on the set of values {a

_{i}} and E(x

_{i}) wherein E(x

_{i}) represents an encryption scheme and the multiplication is carried out mod p (452). For example, the solution involves computing a

_{0}*E(x

_{0})+a

_{1}*E(x

_{i})+a

_{2}*x

_{2}

^{2}*E(x

_{2})+ . . . . The receiver sets y

_{B}to the computation result (454) and sends y

_{B}to the sender wherein y

_{B}is stored for use in authentication (456).

**[0055]**In any embodiment disclosed herein, variations may be made similar to those set forth above wherein particular processing occurs or is viewed from the standpoint of an entity A or an entity B, or a receiver and a sender. Therefore, other embodiments may be generated based on the disclosure herein along these lines.

**[0056]**FIG. 5A illustrates graphically the g

_{i}equation. Block 504 illustrates an A

^{2}value. Here, A equals (((x

_{0}∥x

_{1})+c). Block 504 represents the cst

_{i}and block 506 represents the value of (A>>16)

^{2}wherein ">>" represents a right shift operation of 16 bits. The output of each of these blocks is XORed as shown in block 508. XOR is a bitwise exclusive OR operation that takes patterns of equal length and performs a logical XOR operation on each pair of corresponding bits. The result in each position is 1 if the two bits are different and 0 if they are the same. The operation is carried out mod 2

^{32}. This operation finds the remainder of division of one number by another number and provides the output as shown in block 512.

**[0057]**FIG. 5B graphically illustrates the function G

_{i}. Block 520 squares the A value (defined above), block 522 provides the constant csti

_{i}, and block 524 squares the A value and performs the right shift operation of 32 bits. Thus blocks 520, 522 and 524 provide the input to an XOR operator 566 in a manner similar to that discussed in FIG. 5A. In block 526, B is defined as (((x

_{2}∥

_{3})+c). The B

^{2}in block 526, a constant value csti

_{i}in block 528 and B

^{2}>>32 in block 530 are XORed together 568 to produce the output. This output is added in block 532 with the output from XOR operation 566 mod 2

^{32}in block 534 to produce the output as shown in block 536.

**[0058]**FIG. 5C illustrates one round of key expansion used in the light HMAC scheme. Row 540 illustrates the input x divided in to n number of blocks. In this example, n equals 8. As noted above, in this example, each x

_{i}block is 16 bits. Thus, in row 542 each function g

_{i}receives and processes two blocks of data. Each g

_{i}function receives 32 bits of input data and outputs 32 bits of data to row 544. The various groupings of blocks are then again processed in row 546 by another set of g

_{i}functions, and again outputs 32 bits of data in row 548. This process occurs again, where different sets of data are processed by the g

_{i}functions in step 550 and again provides output in row 552. Again the different inputs are provided to the g

_{i}functions in row 554 and output in row 556. In row 558 each G

_{i}function receives 64 bits of input and compresses the input 64 input bits to 32 bits, output in row 560 as shown. Each block of output in row 560 is XORed in row 564 using the original x

_{i}blocks from row 562 to generate the round output in row 566. The process generates a round key which is stored for later use in the HMAC algorithm.

**[0059]**FIG. 5D provides a simpler view of this key expansion algorithm. Block 570 represents the initial input block which is split into x

_{i}parts and used as input to g

_{i}in step 572. Here, g

_{i}represents the process for each of g

_{0}, g

_{1}, g

_{2}, and g

_{3}. The blocks 574, 5756 and 578 represent multiple applications of the output from one step as the input to another step. Block 580 represents the processing by G

_{i}which output is then XORed with the original x

_{i}from step 570 at 582. FIG. 5D next illustrates that the round key generated in step 584 is used to seed the next round to key expansion. Variations on this approach may be used as well. For example, while four separate processing occurrences of the g

_{i}function are disclosed, the key expansion scheme may increase or decrease the number of times the g

_{i}processed is utilized. Similarly, there may be instances where multiple uses of the G

_{i}process are used as an alternate approach. Typically, the input to the light HMAC scheme may be larger and the output size is fixed.

**[0060]**FIG. 6 illustrates an exemplary method aspect of the disclosure. Here, the input x is split into n number of x

_{i}blocks (602) and the system initializes an input key RK[0] as a key k (604). This is typically an input key that is used for the HMAC process as is known in the art. y is initialized as 0 (606) and the steps involve performing key expansion by, for i=1 to L-1, computing round keys RK[i]=R(RK[i-1]) (608). Next, the system generates an updated y in an iterative fashion as follows:

**[0061]**for i=0 to (n-1):

**[0062]**setting y=y XOR x

_{i};

**[0063]**for j=0 to L-1:

**[0064]**computing y=R(y); and

**[0065]**setting y=y XOR RK[j].

**[0066]**Finally, y is set equal to R(y) (610). The y is output for use in authentication (612).

**[0067]**FIG. 7 illustrates in more detail the step of generating the updated y from step (610) of FIG. 6. The value i is initialized as zero (702) and the system sets y=y XOR x

_{i}(704). The value j is then initialized as zero (706) and y is set to R(y) (708). The value y is calculated to equal y XOR RK[j] (710) and j is compared with the value L (712). If j does not equal L-1, then j is incremented to j+1 (714) and the system returns to step (708) with an incremented j. When j=L-1, the system assigns y=R(y) (716) and next compares i to (n-1) (718). If i does not equal (n-1) (718), then the system increments i as i+1 (720) and returns to step (704). If i does equal (n-1) (718), each x

_{i}block has been processed and the system outputs y (722) for use in authentication.

**[0068]**Therefore, as disclosed above, the process of performing key expansion generates a table of round keys for a predetermined number of rounds L. The key expansion function includes, for each key, performing a function g

_{i}that concatenates members of a first set of bits and XORs the concatenated members with a constant to generate a second set of bits. The function G

_{i}compresses the second set of bits from g

_{i}to generate the compressed output. The compressed output is XORed with the first set of bits to generate a respective round key. The iterative value of y is updated by using the table of round keys in an iterative application of an encryption scheme such as HMAC. Of course, the value y is used for authentication. This approach may then be practiced on different entities to generate the different values y for the different entities. These values can then be compared for authentication purposes as discussed above.

**[0069]**Embodiments within the scope of the present invention may also include computer-readable media for carrying or having computer-executable instructions or data structures stored thereon. Such computer-readable media can be any available media that can be accessed by a general purpose or special purpose computer. By way of example, and not limitation, such computer-readable media can comprise RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to carry or store desired program code means in the form of computer-executable instructions or data structures. When information is transferred or provided over a network or another communications connection (either hardwired, wireless, or combination thereof) to a computer, the computer properly views the connection as a computer-readable medium. A "tangible" computer-readable medium expressly excludes software per se (not stored on a tangible medium) and a wireless, air interface. Thus, any such connection is properly termed a computer-readable medium. Combinations of the above should also be included within the scope of the computer-readable media.

**[0070]**Computer-executable instructions include, for example, instructions and data which cause a general purpose computer, special purpose computer, or special purpose processing device to perform a certain function or group of functions. Computer-executable instructions also include program modules that are executed by computers in stand-alone or network environments. Generally, program modules include routines, programs, objects, components, and data structures, etc. that perform particular tasks or implement particular abstract data types. Computer-executable instructions, associated data structures, and program modules represent examples of the program code means for executing steps of the methods disclosed herein. The particular sequence of such executable instructions or associated data structures represents examples of corresponding acts for implementing the functions described in such steps. Program modules may also comprise any tangible computer-readable medium in connection with the various hardware computer components disclosed herein, when operating to perform a particular function based on the instructions of the program contained in the medium.

**[0071]**Those of skill in the art will appreciate that other embodiments of the invention may be practiced in network computing environments with many types of computer system configurations, including personal computers, hand-held devices, multi-processor systems, microprocessor-based or programmable consumer electronics, network PCs, minicomputers, mainframe computers, and the like. Embodiments may also be practiced in distributed computing environments where tasks are performed by local and remote processing devices that are linked (either by hardwired links, wireless links, or by a combination thereof) through a communications network. In a distributed computing environment, program modules may be located in both local and remote memory storage devices.

**[0072]**Although the above description may contain specific details, they should not be construed as limiting the claims in any way. Other configurations of the described embodiments of the invention are part of the scope of this invention. Accordingly, the appended claims and their legal equivalents should only define the invention, rather than any specific examples given.

User Contributions:

Comment about this patent or add new information about this topic: