PROVIDER

BACKGROUND OF THE INVENTION

[0001 ] The present invention relates generally to verification of attribute assertions, and more particularly to secure electronic devices with mechanisms for providing an unlinkable attribute assertion that is verifiable as having been provided by an certified trusted attribute provider.

[0002] Many activities that humanity has carried out for centuries, if not millennia, can in modern times be performed online over the Internet. Online banking, commerce, auctions, etc. are more-and-more prevalent. In many cases the power of the Internet is both a convenience and a risk.

[0003] As an example, voting, whether in public elections or in the context of organizations and corporations, is one example of such a transformation from paper to electronic protocols. Elections have traditionally been carried out using paper ballots and mechanical voting machines. However, the Internet has brought with it an interest in providing for online elections in which voters may cast their votes using web-browsers, thereby allowing voters the convenience of voting from their homes and offices. Attempts to design such a system have addressed maintaining that convenience while also addressing security, transparency, and fairness concerns.

[0004] A goal for electronic voting is to provide the possibility for voting to occur in places other than at designated voting locations, e.g., at the home or office of a voter or any other location. An electronic voting mechanism is dependent on two conflicting requirements: the anonymity of the voter and verifiability by the election authority that the voter satisfies voter eligibility criteria. If the voter were to simply state his or her name to the election authority, anonymity would be vulnerable. Conversely, if the voter merely states that he or she is a law-abiding adult citizen of the voting jurisdiction, the election authority cannot simply take the voter's word for that or election fraud would be trivial.

[0005] Before discussing problems with digital attribute assertion systems, let's consider some terminology that is used throughout this document: • An attribute is some property associated with an entity, e.g., an individual. Good examples of attributes include age, citizenship, organization membership, criminal record, sex, and civil status.

• An attribute message is a digital message sent from one entity to another to demonstrate that the sending entity has the associated attribute, e.g., "I am a citizen of the Republic of Atlantis" or "I have registered and been determined eligible to vote in the 201 6 Presidential Election." Naturally, these messages would be digitally encoded in a manner known to both sender and recipient.

• An attribute provider is an entity that may provide a certified, e.g., digitally signed, attribute message.

• An attribute asserter is the entity, e.g., an individual, asserting that he or she possesses the attribute, e.g., by sending an attribute message to a service provider needing to verify the possession of the attribute.

• An attribute verifier may be a service provider or an independent entity relied on by the service provider to verify that the attribute message can be trusted.

[0006] One problem associated with attribute assertion mechanisms is that a series of service providers may collude to obtain more information about the attribute asserter than these service providers are entitled to. For example, if the same attribute message is used with several service providers, those providers can collaborate to determine certain characteristics of the attribute asserter. That is undesirable as it compromises the privacy and anonymity of the attribute provider. In addition, the compromised data can be used for purposes not approved by the attribute asserter.

[0007] From the foregoing it will be apparent that there is still a need for an improved technology for providing digital attribute assertions in a manner such that the attribute assertions provided to multiple service providers or attribute verifiers cannot be linked.

SUMMARY OF THE INVENTION

The following summary of the invention is provided in order to provide a basic understanding of some aspects and features of the invention. This summary is not an extensive overview of the invention and as such it is not intended to particularly identify key or critical elements of the invention or to delineate the scope of the invention. Its sole purpose is to present some concepts of the invention in a simplified form as a prelude to the more detailed description that is presented below.

The present invention addresses the aforementioned drawbacks of providing digital attribute assertions in a manner such that the attribute assertions provided to multiple service providers or attribute verifiers cannot be linked.

To achieve those and other advantages, and in accordance with the purpose of the invention as embodied and broadly described, the invention proposes a method for operating an attribute assertion device having a processor and memory to create an unlinkable digital signature-equivalent of an assertion message that is verifiable, by a service provider receiving the unlinkable digital signature-equivalent on a service provider device having a processor and memory, as being generated from a digital signature of a known attribute provider having a public key PKAP wherein the unlinkable digital signature-equivalent is created by the attribute assertion device and verifiable by the service provider device without the sharing of a secret cryptographic key between the attribute assertion device and the service provider device, the method comprising operating the processor of the attribute assertion device to transform a digital signature of the attribute message into an unlinkable digital signature-equivalent using a one-way transformation of the digital signature using a first random number generated by the attribute assertion device, and a challenge provided by the service provider device, the first random number held as a secret by the attribute assertion device.

According to an embodiment of the present invention, the digital signature is in a group G having a generator g, the signature-equivalent is a pair wherein the first member of the pair computed from the first random number _T the challenge (c or g ^c ), and the digital signature, and the second member of the digital signature-equivalent pair is an exponentiation the group generator g to the power of the first random number.

According to an embodiment of the present invention, the method to create an unlinkable digital signature-equivalent of an assertion message according to any previous claims comprises the followings steps:

generating on the attribute assertion device a first random number (/ or

9 ^k )

generating the unlinkable signature-equivalent using the first random number and the challenge provided by the service provider (71 5, 717) ; transmitting the unlinkable signature-equivalent and the shared random number to the service provider; and

on the service provider, verifying the unlinkable signature-equivalent using the challenge, the public key of the known attribute provider, and the shared number.

According to an embodiment of the present invention, the method for operating an attribute assertion device having a processor and memory to create an unlinkable digital signature-equivalent of an assertion message according to the previous claim, further comprises:

on each of the attribute assertion device and the service provider device, computing a value i y that is a function of the shared random number and the challenge provided by the service provider (71 3, 805) ;

wherein the generating of the unlinkable signature-equivalent comprises using the value wto transform the signature into the signature-equivalent using the secret random value (71 5); and

wherein the verifying of the unlinkable signature-equivalent comprises using a bilinear map e to map the unlinkable signature-equivalent, a hash of the attribute message H(M) and known quantities including the public key of the attribute provider, the computed value i y into quantities that may be compared to confirm that the unlinkable signature-equivalent proves that the attribute asserter knows the signature produced by the attribute provider.

According to an embodiment of the present invention, the challenge C is equal to g ^c \n G, and wherein the attribute assertion device computes was {g ^c ) ^k in G, the signature equivalent being the pair S' = (si ', s∑) = {Sw , g ^r ) wherein the s is the digital signature of the attribute message M, w \s {g ^c ) ^k in G, and r is the first random number.

According to an embodiment of the present invention, the service provider device verifies S ' as being an unlinkable signature-equivalent derived from S (the digital signature of the message M) by:

computing w as {g ^c ) ^k \n G;

performing the bilinear mappings v1 = e {H(M), PKAP) where H(M) is a hash of the message M and PKAP is the public key of the attribute provider, v2 = e (s2 g), and v = e {s1 ',g); and

verifying that v = v1 *v2 which proves that s' is derived from s.

According to an embodiment of the present invention, the attribute assertion device computes w as H(k\ \c) wherein c is the challenge from the service provider device, the signature equivalent being the pair S' = (si ', s∑) = {Sw ^r , g ^r ) wherein the s is the digital signature of the attribute message M, w is H(k\ \c), and r is the first random number.

According to an embodiment of the present invention, the service provider device verifies S' as being an unlinkable signature-equivalent derived from S (the digital signature of the message M) by:

compute was H(k\ \c) wherein c is the challenge from the service provider device;

performing the bilinear mappings v1 = e {H(M), PKAP) where H(M) is a hash of the message M and PKAP is the public key of the attribute provider, v2 = e {s2 g), and v = e {s1 ',g); and

verifying that v = v1 ^* v2 which proves that S' is derived from S.

According to an embodiment of the present invention, the service provider device is a server.

According to an embodiment of the present invention, the method to create an unlinkable digital signature-equivalent of an assertion message comprises the following steps:

generating a secret random number r and a shared random number (K) in Zp;

receiving a challenge C from the service provider wherein C is g ^c \n G, c being a random value in Zp, g being a group generator for the group G;

on each of the attribute assertion device and the service provider device, computing a value i y that has the value w=g ^kc of the shared random number and the challenge provided by the service provider (713, 805);

generating the unlinkable signature-equivalent using the secret random number and the challenge provided by the service provider, by:

computing Si' = Sw, and S2' = g ^r , wherein the unlinkable signature- equivalent is S' = S∑)

transmitting the unlinkable signature-equivalent S' and the shared random secret / to the service provider; and

on the service provider, verifying the unlinkable signature-equivalent S' using the challenge, the public key of the known attribute provider, and the shared secret, by:

computing a hash {H(M}) of the attribute message M (805),

computing vi = e{ Η(Μ), ΡΚΑΡΪ)

computing 1/2 = e( S2', w)

computing v = e {S1 g), and verifying that v = v1*v2 as a proof that the attribute asserter device has knowledge of the signature S without revealing S.

According to an embodiment of the present invention, the method to create an unlinkable digital signature-equivalent of an assertion message comprises the following steps:

generating a secret random number (r) and a shared random number (k) in Zp;

receiving a challenge c in Zp;

on each of the attribute assertion device and the service provider device, computing a value wthat has the value w=H(k\ \c) where H(k\ \c) is a hash of the shared random number k concatenated with the challenge C provided by the service provider (71 3, 805) ;

generating the unlinkable signature-equivalent using the secret random number and the challenge provided by the service provider, by:

computing si' = sW, and s∑ = g ^r , wherein the unlinkable signature- equivalent is S' = (si ', s∑)

transmitting the unlinkable signature-equivalent s' and the shared random secret k to the service provider; and

on the service provider, verifying the unlinkable signature-equivalent s' using the challenge, the public key of the known attribute provider, and the shared secret, by:

computing a hash {H(M)) of the attribute message M (805),

computing vi = e{ Η(Μ), ΡΚΑΡΪ)

computing v∑ = e{ S2', w)

computing v = e (S1 g), and

verifying that v = v1*v2 as a proof that the attribute asserter device has knowledge of the signature s without revealing s.

The present invention is also related to an attribute assertion device having a processor, memory, and instruction storage, the instruction storage comprising instructions to cause the attribute assertion device processor to perform the method for operating an attribute assertion device to create a digital signature-equivalent as claimed.

The present invention is also related to a service provider device having a processor, memory, and instruction storage, the instruction storage comprising instructions to cause the service provider device processor to verify an unlinkable digital signature-equivalent provided by the attribute assertion device. BRIEF DESCRIPTION OF THE DRAWINGS

[0008] Figure 1 is a schematic illustration of a network connecting a citizen-host computer with a portable security device, e.g., an electronic identity card, connected thereto to one or more online servers described in greater detail herein below.

[0009] Figure 2 is a top-view of an exemplary attribute assertion device, for example, as herein, an electronic identity card, here implemented as a smartcard.

[0010] Figure 3 is a schematic illustration of the hardware architecture of an electronic identity card, specifically, a chip-module of an electronic identity circuit card, which may be considered an exemplary attribute assertion device.

[001 1 ] Figure 4 is a schematic illustration of computer programs loaded onto an attribute assertion device, e.g., an electronic identity card, as well as data such as cryptographic keys supporting cross-domain unlinkable pseudonym applications used as described herein below.

[0012] Figure 5 is a high-level timing-sequence diagram that illustrates a first embodiment providing unlinkability of attribute messages provided to multiple service providers.

[0013] Figure 6 is a timing sequence diagram illustrating the computation of the signature equivalent S' corresponding to the signature S of an attribute message M by the service provider A according to an embodiment of the invention.

[0014] Figure 7 is a flow-chart illustrating the process of producing a signature-equivalent s' beginning with the creation of the corresponding digital signature s.

[0015] Figure 8 is a flow-chart illustrating the steps of the service provider attribute verification device to verify the signature-equivalent s' as a true equivalent of a signature s produced by the attribute provider device.

DETAILED DESCRIPTION OF THE INVENTION

[001 6] In the following detailed description, reference is made to the accompanying drawings that show, by way of illustration, specific embodiments in which the invention may be practiced. These embodiments are described in sufficient detail to enable those skilled in the art to practice the invention. It is to be understood that the various embodiments of the invention, although different, are not necessarily mutually exclusive. For example, a particular feature, structure, or characteristic described herein in connection with one embodiment may be implemented within other embodiments without departing from the spirit and scope of the invention. In addition, it is to be understood that the location or arrangement of individual elements within each disclosed embodiment may be modified without departing from the spirit and scope of the invention. The following detailed description is, therefore, not to be taken in a limiting sense, and the scope of the present invention is defined only by the appended claims, appropriately interpreted, along with the full range of equivalents to which the claims are entitled. In the drawings, like numerals refer to the same or similar functionality throughout the several views.

[0017] In an embodiment of the invention, a technology is described which provides a secure electronic device with a mechanism by which the secure electronic device can provide a service provider with a certified attribute message that cannot be linked to other attribute messages even if the attribute messages correspond to the same attribute for the same entity (e.g., same individual).

[0018] Electronic voting is used herein to provide a context to illustrate the usefulness of the presented technology. However, the technology is in no way limited to electronic voting. Other applications include online commerce, mobile commerce, mobile-ID that can be used to provide physical access to a physical facility, and access to online resources only available based on a user satisfying some attribute, for example, age or membership to an organization.

[0019] Figure 1 is a schematic illustration of a network 1 1 1 connecting a citizen-host computer 103 with an attribute assertion device 109, here a portable security device 109a, e.g., in the form of an electronic identity card, connected thereto to one or more online servers described in greater detail herein below. The citizen-host computer 103 is operated by a user 101 who operates a web browser window 105 of a web browser. In the particular context of the present technology the user 101 is a voter in an online election; for example, the user 101 may be a citizen who wishes to cast a vote in a public election. In the example scenario illustrated in Figure 1 , the portable security device 109 may be an electronic citizen identity card. In alternative implementations the portable security device 109a may be any other electronic identity card that provides privacy while operating to identify the holder of the device. While the presented technology is very useful in the context of portable security devices, it is also applicable to other devices that may be used by an entity, e.g., an individual, to prove possession of an attribute.

[0020] As is discussed in greater detail herein below, the user 101 (also referred to herein as voter 101 ), operates the web browser (via the browser window 105) to connect to a server 1 13a administered by a first election authority 1 12a to cast a vote in an election. The election authority 1 12a operates one or more servers 1 13a, hereinafter, election authority server computer(s) 1 13a. Having confirmed that a voter 101 is allowed to vote in an election, by way of verifying an attribute message provided to the election authority server 1 13a, the election authority server computer's role is to record the voter's vote.

[0021 ] The voter 101 also operates the web browser to connect to one or more servers 1 15a operated by a registration authority 1 14a. The registration authority's role in the administration of elections is to verify that a voter is eligible to vote in the election. As such, the registration authority may provide an attribute message attesting to the eligibility of the user 101 to vote. That attribute message is provided to the user 101 for storage on the identity card 109a of the user 101 .

[0022] To prove that the user 101 satisfies the eligibility criteria there may be certain attributes, e.g., age, voting jurisdiction, and citizenship, preloaded on the identity card 109a when the card is personalized for the user by a citizenship office 1 14b using the attribute provider device 1 15b. Conversely, since the registration authority 1 14a verifies voter eligibility, it acts also as an attribute verifier, in this example; thus, the server operated by the registration authority 1 14a may also be viewed as an attribute verification device 1 13c.

[0023] As noted above, the voter registration attribute may be used in multiple independent elections. For example, the voter registration may be used in national elections as well as in local elections. Thus, there may be many election authorities, for example, as depicted in Fig. 1 , election authority 1 12b operating the election authority server which operates as an attribute verification device 1 13b. To assure anonymity and privacy, the multiple election authorities should not be able to link the attribute messages provided to them by the user 101 even if the underlying attribute is the same voter registration attribute.

[0024] Figure 2 is a top-view of an electronic identity card 109a, for example, implemented here as a smartcard. The electronic identity card 109a typically encompasses a plastic substrate 201 . The integrated circuit card further includes an embedded integrated circuit card chip 205, which is typically connected to a contact pad 207. In alternative embodiments, the integrated circuit card chip may connect to external readers using connectors such as Universal Serial Bus (USB) connectors or wirelessly using techniques such as near-field communication (NFC) or radio-frequency identification (RFID) protocols.

[0025] The electronic identity card 109a typically includes some physical identifying information, e.g., a logo 209 identifying the issuing country of origin, a photograph 203 and a name 21 1 of the person who is citizen to which the electronic identity card has been issued, i.e., herein the voter 101 . While these are mere visual manifestations of the personal nature of the electronic identity card 109a, they are indicative of the personal nature of each individual card. The issuing authority also personalizes the specific electronic identity card 109a assigned to a citizen by storing information pertinent to that citizen and with applications that the citizen can execute using the identity card 109a in non-volatile memory of the card. For example, cryptographic keys associated with the citizen may be stored on the identity card 109a during card personalization. These cryptographic keys include the private key of the citizen. Furthermore, as discussed herein below, the identity card 109a may store attribute messages provided by an attribute provider, a public key of the attributed provider, and associated signatures.

[0026] The electronic identity card 109a may further store biographic information such as name, date-of-birth, gender, address, nationality, municipality etc. of the holder of the card. This information may be stored in the form of digital attributes as described herein below.

[0027] Figure 3 is a schematic illustration of the hardware architecture of an exemplary attribute assertion device 109, specifically, the chip-module 205 of an electronic identity circuit card 109a. The chip-module 205 may include a processor 301 connected via a bus 302 to a random access memory (RAM) 303, a read-only memory (ROM) 304, and a non-volatile memory (NVM) 305. The chip-module 205 further includes an input/output interface 307 for connecting the processor 301 , again typically via the bus 302, to the connector pads 207 by which the electronic identity card 109a may be connected to a card reader. The electronic identity card 109a may alternatively connect to the outside world wirelessly and would in such embodiments typically include an antenna rather than the connector pads 207. It should be noted that the chip-module 205 may, alternatively, be located in a SIM card (also known as a Universal Integrated Circuit Card (UICC)), embedded Secure Element (GlobalPlatform, GlobalPlatform made simple guide: Secure Element, https://www.alobalplatform.org/mediaauideSE.asp. accessed on, July 27, 2015), a Micro SD card, or similar secure device.

[0028] The ROM 304 may or may not be present. Herein is described a technology in which much of the functionality that has hitherto been placed in ROM is now located in the NVM 305. However, that does not preclude that the electronic identity card 109a has a ROM for some other purpose.

[0029] Figure 4 is a schematic illustration of computer programs

401 that may be loaded onto an attribute assertion device 109, for example into the NVM 305. While it is here depicted that the computer programs 401 are all co-located in the NVM 305, in actual practice there is no such restriction as programs may be spread out over multiple memories and even temporarily installed in RAM 303. The programs 401 include operating system programs as well as application programs loaded on to the electronic identity card 109. While Figure 4 illustrates example contents of an example attribute assertion device 109, other embodiments of an attribute assertion device 109 may include other contents and may not necessarily include all the items illustrated in Figure 4.

[0030] The attribute assertion device 109 programs 401 may include the operating system OS 219 as well as other system programs 213, e.g., cryptography module 213', user authentication module 213", and communications module 213"'. The system programs 213 may include whatever functionality the electronic identity card 109 is required to perform, for example, cryptography and communications aspects of the methods described herein.

[0031 ] The attribute assertion device 109 programs 401 may further include a cross-domain unlinkable attribute module 215 for causing the attribute assertion device 109 to perform card-side operations of a cross- domain unlinkable attribute operation as described in greater detail herein below, for example, in conjunction with Figures 5 through 8. The cross-domain unlinkable attribute module 215 contains a key material module 217 to cooperate with a service provider 1 12 attribute verification device 1 13 to create key material that may be used to provide a digital-signature equivalent s' of a digital signature s of an attribute message M. The cross-domain unlinkable attribute module 215 further includes a transformation function 219 for transforming the digital signature s into the digital signature-equivalent s' using the key material created with the service provider attribute verification device 1 13. A property of a digital-signature equivalent s' is that the service provider attribute verification device 1 13 may verify that the signature-equivalent s' was created from a legitimate signature s from a known attribute provider without the signature s being revealed. Further subsequent signature-equivalents may not be linked, e.g., if both s" and s' were generated from s, that fact cannot be determined from viewing s" and s' separately or together.

[0032] The memory 305 may also store a number of attribute messages 221 . Attributes 221 may be data structures that prove to an inquirer that the holder of the electronic identity card 109 satisfies some particular quality, e.g., citizenship, without revealing the identity of the holder of the electronic identity card 109. Thus, if a voter 101 must establish that he or she is a citizen of a jurisdiction holding an election, the administration of the election may request the citizenship attribute 223 be provided by the electronic identity card 109. Other attributes useful in a public election context include age 225 and municipality 227. Further, a person's criminal record 229 may disqualify a potential voter. In special elections such as elections run by a particular organization, such as a national union, membership 231 to the organization may be relevant. Alternatively, an attribute may simply be a credential signifying that the voter 101 is eligible to vote in a given election.

[0033] An attribute message is a data structure provided by an attribute provider 1 15 that makes an assertion about some characteristic, e.g., as here, the eligibility to vote. The attribute provider 1 15 is an external entity that has some knowledge about the characteristic being asserted by the attribute, i.e., a government entity that keeps citizenship records. The attribute assertion is provided as a message, the attribute message, which is digitally signed by the attribute provider using the attribute provider's private key. Thus, a verifier may verify that the assertion made via the attribute is correct by verifying the signature provided as being that of the attribute provider. Herein, attribute, unless the context is clear to the contrary, refers to such a digital attribute provided by an attribute provider. Thus, each attribute message, M, has a digital signature, s, associated therewith. The digital signature s is created by the attribute provider 1 15 using a private key SKAP. The corresponding public key PUAP S known by all the parties, e.g., the attribute asserter and the service provider. [0034] Thus, when an attribute assertion device 109 provides an attribute, e.g., citizenship 223, that attribute is a signed data item, an attribute message M, that (1 ) asserts the citizenship and that (2) may be verified as having been provided by a trusted attribute provider based on a digital signature s of the attribute provider.

[0035] Turning now to use of the technology to provide for a secure and flexible mechanism for providing unlinkable attributes according to several embodiments.

[0036] Figure 5 is a high-level timing-sequence diagram that illustrates a first embodiment providing unlinkability of attribute messages provided to multiple service providers. The described mechanism for providing unlinkability of attributes as described herein protects the attribute message against linking the signatures (or more accurately, equivalents to the signatures) provided to different service providers as corresponding to one original signature.

[0037] The attribute provider 1 14, specifically on an attribute provider device 1 15, has in its possession keys 501 by which it may sign the attribute message M producing a digital signature S. The attribute provider 1 14 may further be in possession of a digital certificate 503 that proves that the attribute provider 1 14 is the true owner of the key used to sign the attribute message M. The signature S may be used to create unique signatures for each assertion of the attribute to one or more service providers.

[0038] As will be discussed in greater detail herein below, the signature S is produced by the attribute provider using cryptographic keys. In a preferred embodiment discussed herein below, a public key cryptography key pair, i.e., comprising a private key and public key, is used for this purpose. Specifically, the private key is used for signing the attribute message and the public key may be used to verify the signature. These keys are transmitted to any service provider attribute verification device 1 13 that needs to verify an attribute message and the associated signature equivalent, Step 504.

[0039] Step 505. The attribute provider 1 14 signs the attribute message M producing the signature S.

[0040] Step 507. The attribute provider 1 14 transmits the attribute message M and the digital signature S to the attribute asserter 109. This step may be either during the personalization of the attribute asserter security device 109a or may be provided at a later stage, for example, in conjunction with an online communication such as when the user 101 demonstrates to an attribute provider that he or she satisfies the criteria associated with the attribute. The attribute asserter 109a may then use the signature S to produce signature equivalent contents that are unique to each service provider to which the attribute asserter wishes to assert the attribute. The mechanism for that is discussed in greater detail below in conjunction with Figures 6 and 7.

[0041 ] Step 509. The attribute asserter 109 transforms the signature S into an unlinkable signature equivalent S' that corresponds to a service provider A attribute verification device 1 13a.

[0042] Step 51 1 . The attribute asserter 109 transmits the attribute message M and the unlinkable signature equivalent S' to the service provider A attribute verification device 1 13a.

[0043] Step 513. If the attribute asserter 109 wishes to use the same signature Swith another service provider, say service provider B attribute verification device 1 13b, the attribute asserter 509 transforms the signature S into yet another equivalent S", this time corresponding to the service provider B attribute verification device 1 13b.

[0044] Step 515. The attribute asserter 109 transmits the attribute message M and the unlinkable signature equivalent S" to the service provider B attribute verification device 1 13b.

[0045] Properties of the signature equivalents S' and S" include that the attribute asserter 109 creates both (and any further signature equivalents associated with yet other service providers) from the same signature S, that the service provider attribute verification devices 1 13 may verify that the signatures S' and S" correspond to a valid signature S that is a signature of the attribute message M, which was signed by the attribute provider device 1 15 using the key of the attribute provider, e.g., the public key of the attribute provider. However, it is not possible to derive S from S' or S". Furthermore, it is not possible to link S' and S" (or any other signature equivalent produced as described herein below).

[0046] Step 517. The Service Provider A attribute verification device 1 13a verifies that S'corresponds to a signature Sthat is a valid signature of M when signed by the key of the attribute provider. The Service Provider A attribute verification device is aware of a key belonging to the attribute provider that signed M, which can then be used to verify the authenticity of a signature- equivalent without knowing the signature. As the attribute provider does not provide S but S', the attribute verifier uses a special technique, described herein below, to verify the correspondence of S'to S. [0047] Step 519. The Service Provider A attribute verification device 1 13a accepts the attribute assertion associated with the attribute message M if the correspondence between a public key PKAP of the attribute provider that signed Mand S'is verified. As noted, this verification is performed without the knowledge of S; only the signature-equivalent S', the public key PKAP, and the message are known to an attribute verification device 1 13.

[0048] Steps 521 and 523. The service provider B attribute verification device 1 13b performs a similar correspondence verification vis-avis the signature S" that results from an attribute assertion of the attribute provider device 1 15 with the service provider B attribute verification device 1 13b.

[0049] Figure 6 is a timing sequence diagram illustrating the computation of the signature equivalent S' corresponding to the signature S of an attribute message M by the service provider A according to an embodiment of the invention. Naturally, the computation proceeds in a similar fashion for other service providers.

[0050] The technology described herein relies on the abstract algebra concept of groups. The mathematics of groups is beyond the discussion of this paper. The reader is referred to John A. Beachy and William D. Blair, Abstract Algebra, 3d. Edition, Waveland Press Inc., Long Grove, Illinois (incorporated, in its entirety, herein by references) for a detailed explanation of abstract algebra including groups. Another important mathematical concept used herein is algebraic pairing. An accessible discussion of pairings may be found in Craig Costello, Pairings for beginners, https://www. Qoogle. com/url?sa= t& rct=i&g=&esrc=s&source= web& cd= 1 & cad= ria&uact=8& ved=0CB4QFiAAahUKEwiinMThmeHiAh VSzmMKH YIBBiY& ur = h ttp%3A %2F%2Fwww. craigcostello. com.au%2Fpairings %2FPairingsForBeain ners. odf& usa=AFQiCNHW8PdtL I WvaaFE u EfwEcCieia a, accessed on October 26, 2015. Costello is incorporated herein by reference in its entirety. The technology described herein is based on D. Boneh, C Gentry, H. Shacham and B. Lynn, Aggregate and Verifiably Encrypted Signatures from Bilinear Maps, Eurocrypt 2003, LNCS 2656, pp. 41 6-432, 2003 (http:.7crvDto. stanford.edu/---dabo/pubs/papers/aqqreq.pdf, accessed on October 26, 2015). Boneh et al. is incorporated herein by reference in its entirety.

[0051 ] In a preferred embodiment, the attribute provider device

1 15 uses public key cryptography to sign the attribute message M. Thus the attribute provider has associated therewith a PKI key pair 601 : public key PKAP and a private (secret) key SKAP. In an alternative embodiment a shared secret may be used.

[0052] Step 603: The attribute asserter, e.g., an individual seeking to assert an attribute such as citizenship, operates the attribute asserter device 109 to request an attribute.

[0053] Step 605: The attribute provider device 1 15 creates an attribute message M and digitally signs the attribute message M using the attribute asserter's private key SKAP producing a digital signature S. This step may be made during the issuance of a device to the attribute asserter. For example, if the attribute asserter device is an electronic identification card with an embedded integrated circuit card, the attribute message M, the digital signature s, and the public key PKAP that corresponds to private key SKAP and that was used to sign the attribute message M may all be stored on the attribute asserter device 109 during, for example, personalization of the device.

[0054] Step 607: Alternatively, i.e., if the attribute asserter device 109 is not pre-provisioned with the attribute message M, the digital signature S, and the public key PKAP, these quantities are transmitted by the attribute provider device 1 15 to the attribute asserter device 109. The three quantities do not necessarily have to be provided by the attribute provider. For example, public key PKAP for the attribute provider may be obtained from a third party. Optionally, the public key PKAP may be accompanied by a digital certificate from a certificate authority to further demonstrate the veracity of the digital signature s.

[0055] Step 609: the public key of the attribute provider, PKAP, as well as the optional certificate are also provided to a service provider attribute verification device 1 13 to which the user is seeking access. As illustrated here the public key PKAP and certificate are transmitted from the attribute provider device 1 15 to the service provider attribute verification device 1 13. However, this may happen at any time, e.g., the service provider attribute verification device 1 13 may be provisioned with the attribute provider key and certificate at the time that the attribute provider device 1 15 is first issued to a user as part of an issuance of related devices. The public key PKAP and the certificate are not necessarily provided by the attribute provider. For example, a third party may act as a repository for public keys and certificates for a number of attribute providers. [0056] Step 61 1 : The utility of the attribute message M is to allow for the assertion of the associate attribute with a service provider 1 12. For example, the attribute may be used to establish that the user is a member of a particular group of people who have the right to access the service provider services. Thus, a connection is established between the attribute asserter device 109 and the service provider attribute verification device 1 13 that requires confirmation that the user possesses a required attribute.

[0057] While not illustrated in Figure 6, the user may be operating a web browser session with the service provider attribute verification device 1 13 on a user computer different from the attribute asserter device 109, for example, a host computer having a smart card connected thereto and acting as the attribute asserter device 109 or a mobile telephone and a UICC installed therein wherein the UICC acts as the attribute asserter device 109. That web session may then initiate a communications link between the attribute asserter device 109 and the service provider device attribute verification device 1 13, often referred to as a service provider server.

[0058] Step 613: To demonstrate that the user has the desired attribute the service provider attribute verification device 1 13 transmits a challenge C to the attribute asserter device 109. The challenge C is used by the attribute asserter to demonstrate that it is in possession of the signature s from the attribute provider device 1 15 without revealing S. Typically the challenge C would be a random value generated by the service provider attribute verification device 1 13.

[0059] Step 615: the attribute asserter device 109 computes a signature-equivalent S' as a function of s and C. As discussed herein below, the signature-equivalent S' may be used by the service provider device 1 13 to confirm that the attribute asserter device 109 is in possession of S and that S is a valid signature of the attribute message M. The computation of S' by the attribute asserter device 109 is described herein below.

[0060] Step 617: the attribute asserter device 109 responds with the attribute message M and the signature-equivalent S'. Any other material needed by the service provider to verify S' without revealing S may also be transmitted to the service provider 1 13 (see discussion herein below in conjunction with Step 719 of Figure 7).

[0061 ] Step 619: the service provider attribute verification device 1 13 receives the attribute message M and the signature-equivalent S'. The service provider attribute verification device 1 13 verifies that S' corresponds to a valid signature S from the attribute provider device 1 15 using the public key PKAP of the attribute provider and the challenge C.

[0062] Step 621 : if the verification result confirms that S' corresponds to a valid signature S of the message M, then access to the desired service is provided. Otherwise, service is denied.

[0063] Turning now to the computation of S' by the attribute asserter device 109 in Step 615. Every time that the attribute asserter device 109 wishes to use the pair attribute message M and the associated digital signature s to communicate an attribute assertion to a service provider attribute verification device 1 13, the attribute asserter device receives the challenge C from the service attribute verification device 1 13. The attribute asserter device 109 transforms the signature s using a mathematical transformation T (r,k,C,S) -> S'. The elements r and / in this equation are random values generated by the attribute asserter device 109 and C is the challenge sent by the service provider attribute verification device 1 13 in step 613.

[0064] One desirable characteristic of the transform T is that it should be difficult to discern S from S'. It should also be difficult to discern that S' and S" are both derived from S (i.e., it should not be possible to tell if S' = T{r',k',C',S) and S" = T{r",k",C",S) or if S' = T{r',k',C',s) and S" = T{r",k",C",S ^* ) where S≠ S*.

[0065] For state-of-the-art verifiable encrypted signature, an external party (an adjudicator) possesses an adjudicator's public key PKadj and corresponding private key SKadj. The signature s is encrypted with the public key PKadj and the adjudicator uses the private key SKadj to ensure that the verifiable encrypted signature is valid. In this context the message is signed by the prover (device).

[0066] Conversely, according to an embodiment of the present invention, the public key is created interactively by the device and the service provider; this public key is created dynamically and it is used only for the purpose of one authentication protocol; in other words, that one-use public key is used to transform the signature s for one particular incident of authentication. Therefore, no one knows the corresponding private key. The attribute asserter (operating attribute asserter device 109)is ensured that the service provider attribute verification device 1 13 (as well as anyone else) cannot link the transformed (encrypted) s' with the secret s. And the service provider 1 13 is ensured that the device knows the secret s. [0067] A transformation T according to the invention uses a bilinear map e as follows:

[0068] Let Gi and G∑ be two multiplicative groups of prime order p; gi is a generator of Gi and g∑ is a generator of G∑. Let GT be also a group of prime order p The map e is a computable bilinear map, e Gi x G2→ GT

[0069] For simplicity, consider in the following that G = Gi = G∑ where g is the generator of G. However, in an alternative embodiment, the condition may be Gi≠ G2. The map e is then a computable bilinear map, e : G x G→ GT ^■ The map is a pairing from which it follows that for all a and b, e(g ^a , g ^b ) = e(g, g ^ab ). The map is not-degenerate; i.e., e(g,g)≠ 1 .

[0070] Another aspect of the technology to prepare an unlinkable attribute assertion is a hash function H. The hash function H is defined such that H: (0,1 ) ^* -> G. In the general case, H is a hash function H: {0,1 } ^* → Gi. In one embodiment the hash function H is SHA-256.

[0071 ] As noted above, the attribute provider / ^' , AP, 109 is related to a private key SKAPI, which is denoted here as x, where x is an integer in Zp. The corresponding public key, PKAPI, is defined as PKAPI = g ^x where g is the generator for a group G.

[0072] Figure 7 is a flow-chart illustrating the process of producing a signature-equivalent s' beginning with the creation of the corresponding digital signature s.

[0073] Step 701 : The attribute provider device 1 15 signs the attribute message M using the hash function H and the attribute provider's private key x (also, PKAPI) :

s = H{M)x

[0074] where H(M) is in G.

[0075] Step 703 (e.g., Step 607 (Figure 6)): the signature S is securely provisioned to the attribute asserter device 109.

[0076] Step 705: For each use of the pair M, S the attribute provider device 109 performs the following steps:

[0077] Step 707: Generate a random value r in Zp

[0078] Step 709: Generate a random value k in Zp

[0079] Step 71 1 : Receive the challenge from the service provider attribute verification device 1 13. In a first embodiment, the challenge is C=g ^c in G with c in Zp. In a second embodiment, the challenge is simply c in Zp.

[0080] Step 713: Compute w. In the first embodiment, where the challenge is C = g ^c , w = g ^kc . In the alternative embodiment, wherein the challenge is c in Zp, w = H(k\\c) wherein k\\c is a concatenation of the random value / and c.

[0081 ] The attribute asserter may, optionally, also compute H(M) to verify that the signature S corresponds to the message M.

[0082] Step 715: Compute si = sW

[0083] Step 717: Compute s ₂ ' = g ^r

[0084] The signature-equivalent s' is the pair (si, S2 ). In other words, the above calculations operate to transform the signature S into S' as

S' = (si, S2 ) = (swr, g ^f )

[0085] Random value r remains a secret only known to the attribute asserter 109. However, in the first embodiment, K=g ^k is transmitted to the service provider attribute verification device 1 13. The random value k alone is transmitted to the service provider attribute verification device 1 13 in the second embodiment.

[0086] Step 719 (Step 617): The signature-equivalent s' is transmitted to the service provider attribute verification device 1 13 together with the random value K or k (in the second embodiment).

[0087] Figure 8 is a flow-chart illustrating the steps used by the service provider attribute verification device 1 13 to verify that the signature- equivalent S' as a true equivalent of a signature s produced by the attribute provider device 1 15.

[0088] Step 801 : The quantities c or C (depending on whether the challenge is c or C = g ^c , g, and PKAP are known by the service provider 1 13. The challenge C = g ^c or c is generated by the service provider attribute verification device 1 13 and transmitted to the attribute asserter device 109 as a challenge, g is the generator for the group G; this value is pre-agreed upon by the parties involved. Alternatively, attribute provider 1 15 or attribute asserter 109 may provide this value to the service provider attribute verification device 1 13; it is not a secret quantity. Similarly, PKAPI, the public key of the attribute provider 109, is provided by the attribute provider 109 to the service provider attribute verification device 1 13 in message 504 (Figure 5).

[0089] Step 803: The service provider attribute verification device 1 13 receives the attribute message M and the value K=g ^k or the random value k, respectively, depending whether the challenge is C = g ^c (first embodiment) or c (second embodiment) from the attribute asserter 109.

[0090] Step 805: The service provider attribute verification device 1 13 computes the values H(M) and w = K ^c = g ^kc (first embodiment) or H(k\\c) (second embodiment). The same hash function H is used as the hash function used by the attribute asserter 109.

[0091 ] Step 807: The service provider attribute verification device 1 13 computes a value vi using the mapping function e introduced hereinabove: vi = e{H{M), PK _A pi)

where, H(M) is the hash value computed in Step 805 and PKAPI is the public key of the attribute provider device 1 15

[0092] Step 809: The service provider attribute verification device 1 13 computes a value v∑ using the mapping function e introduced hereinabove: v∑ = e{s ₂ ',w)

where, S∑' is the second member of the pair (si', s∑) which is provided as the signature-equivalent s in Step 803 and PKAPI is the public key of the attribute provider 1 15.

[0093] Step 81 1 : The service provider attribute verification device 1 13 computes a value v using the mapping function e introduced hereinabove:

[0094] Step 813: As is shown herein below, the quantity v should equal the product v ^* v∑ if S' is indeed generated from a signature s produced by the attribute provider device 1 13 using the public key PKAPI. Accordingly, the service provider performs the comparison to determine if v = v ^* v∑.

[0095] Step 815: If the verification of v = v ^* v∑ has been established, then the attribute of attribute message M is proven, and the service provider attribute verification device 1 13 grants the user access to the service requested.

[0096] Turning now to an explanation proving the correctness of the calculation of Figure 8 to verify that s' is a correct signature-equivalent of the signature s as provided by the attribute provider device 1 15.

[0097] As noted above the bilinear mapping e(a,b) in G is a pairing. A property of a pairing is that:

e{g ^a ,g ^b ) = e (g, g ^ab )

[0098] From this, it follows that:

for any x, y in G

[0099] vi ^* v∑ is by definition:

vi ^* v∑ = e{ H(M), PKAPI ) ^* e{ s∑',w )

[0100] PKAPI was generated using g ^x and s∑ was calculated as g ^r .

Thus, we can substitute these quantities for PKAPI and s∑, respectively: vi * V2 = e{ H(M), g ^x ) ^* e{g ^r ,w )

[0101 ] Apply the property that e{x ^a ,y ^b ) = e{x,y ^ab ) :

vi ^* v ₂ = e{ H{M)\ g) ^* e g,w)

[0102] It is a property of a pairing that e{x,g) = e (g,x), from which the above may be arranged as:

vi ^* v ₂ = e{ H{M)\ g) ^* e(wr, g)

[0103] It is also a property of a pairing that e{x,g) ^* e(y,g)=e(x ^* y, g). Therefore, the above may be re-written as:

vi ^* v ₂ = e{ H(M) ^x* i y, g)

[0104] Substitute s for H(M) ^X

1 7 ^* i 2 = e( s ^* W, g)

[0105] By definition si' = s ^* W . Thus, the above may be rewritten as

[0106] Note that v was independently computed as e (Si ', g) in

Step 81 1 . Thus, i/should equal v1 ^* v2. This results confirms that the verification process of Figure 8 confirms from s' that the message M was signed by the attribute provider having the key pair SKAP, PKAP.

[0107] From the foregoing it is apparent that a technology is described herein for enhancing a secure electronic device by providing unlinkable attribute messages in a secure, flexible and efficient manner. The attribute messages may be verified as having been signed by an authorized attribute provider. While the attribute message may be verified as having been signed by an attribute provider, subsequent assertions of the attribute message may not be linked to the original assertion because all attribute assertions will use different signature-equivalents as each is derived from a new challenge from the service provider as well as using random numbers generated and kept secret by the attribute asserter.

[0108] Although specific embodiments of the invention have been described and illustrated, the invention is not to be limited to the specific forms or arrangements of parts so described and illustrated. The invention is limited only by the claims.