METHOD FOR AUTHENTICATING ATTRIBUTES IN A NON-TRACEABLE MANNER AND WITHOUT CONNECTION TO A SERVER

Abstract

The present invention relates to a method, for a provider entity belonging to a provider group, to authenticate its belonging to an attribute provider group to a verification entity in a non-traceable manner without necessitating to share secret or large constants compromising privacy. Both entities comprise at least one attribute group arborescence, this attribute group arborescence being shared by the provider entity and the verification entity when the provider entity has the attribute. According to the invention, when a verification is triggered, the verification entity calculates a certificate from the attribute group arborescence, said certificate being calculated from the authentication tokens of the groups along the arborescence from the attribute verification group's token to the consumer group's token.

Claims

1. Method, for a provider entity belonging to a provider group, to authenticate its belonging to an attribute provider group to a verification entity belonging at least to a consumer group and to an attribute verification group, in a non-traceable manner without necessitating to share secret or large constants compromising privacy, both entities comprising at least one attribute group arborescence, this attribute group arborescence being shared by the provider entity and the verification entity when the provider entity has the attribute, each group being authenticated by an authority that stores a group secret key into the entities under its authority, comprising the preliminary step of providing each entity from each group with a set of authentication tokens, one for each of the other groups with which the entity is intended to communicate, said authentication token comprising at least a random number and a cryptogram of at least this random number by the secret key of each of these other groups; said method further comprising the steps of, when a verification is triggered, for the verification entity, calculating a certificate from the attribute group arborescence, said certificate being calculated from the authentication tokens of the groups along the arborescence from the attribute verification group's token to the consumer group's token, establishing a secure channel based on the exchange of the cryptograms of the provider group and of the consumer group and sending the calculated certificate to the provider entity, for the provider entity, receiving and decrypting said certificate using the successive keys of the groups in the arborescence, using the decrypted random number of the authentication token of the attribute provider group to establish an attribute level's secure channel with the verification entity.

2. Method according to claim 1, wherein a challenge is further exchanged once the attribute level's secure channel is established.

3. Method according to claim 1, said method comprising a provision of a set of new authentication tokens for each level of the arborescence, this provision comprising the steps of calculating a token provisioner from the attribute group arborescence, said token provisioner being calculated, like the certificate, from the authentication tokens of the groups along the arborescence from the attribute provider group's token to the provider group's token, sending the token provisioner through the secure channel to the verification entity, for the verification entity, receiving and decrypting said token provisioner using the successive keys of the groups in the arborescence, storing the extracted new authentication tokens at each levels after decryption.

4. Method according to claim 1, wherein said certificate is calculated for each group from lower group data in the arborescence, said data including at least an identifier of the lower group, the cryptogram of the lower group and, except for the attribute verification group, the previously calculated certificate for the lower group, said calculation including the encryption of at least the identifier of the lower group, the cryptogram of the authentication token for the lower group and the certificate of the lower group using the random number of the authentication token of the group.

5. Method according to claim 1, wherein additional parameters are introduced in the certificate.

6. Method according to claim 5, wherein said additional parameters are chosen among the group constituted by: new authentication token, specific operation code, revocation code, certificate checking code, addition of groups code, transaction parameters such as validity checking, payment amount, agency identifier, transaction role, timestamps limiting the validity, timestamps starting the validity at a given date, a duration, a count.

7. Method according to claim 1, the lower group being associated to an attribute identifier, the method comprises the step of, if the attribute identifier is unique or not ambiguous in the scope of an application, for the attribute provider group, accepting the request or denying it.

8. Method according to claim 7, wherein the acceptation or deny is decided in relation with a user's agreement or policy according to an application profile.

9. Device comprising a provider entity belonging to a provider group and able to authenticate its belonging to an attribute provider group to a verification entity belonging at least to a consumer group and to an attribute verification group, in a non-traceable manner without necessitating to share secret, said provider entity comprising at least one attribute group arborescence, this attribute group arborescence being shared by the provider entity and the verification entity when the provider entity has the attribute, each group being authenticated by an authority that stores a group secret key into the entities under its authority, said provider entity being provided with a set of authentication tokens, one for each of the other groups with which the device is intended to communicate, said authentication token comprising at least a random number and a cryptogram of at least this random number by the secret key of each of these other groups; said provider entity being configured to establish secure channels with the verification entity; said provider entity being further configured to, when a verification is triggered, receive, via a secure channel based on the exchange of the cryptograms of the provider group and of the consumer group, a certificate calculated from the attribute group arborescence by the verification entity, said certificate being calculated from the authentication tokens of the groups along the arborescence from the attribute verification group's token to the consumer group's token, said provider entity further comprising a decryption unit to decrypt said certificate using the successive keys of the groups in the arborescence, said provider entity being further able to establish an attribute level's secure channel with the verification entity using the decrypted random of the authentication token of the attribute provider group.

10. Device comprising a verification entity belonging to a consumer group and to an attribute verification group, said verification entity being dedicated to verify the authentication of the belonging to an attribute provider group of a provider entity, said verification entity comprising at least one attribute group arborescence, this attribute group arborescence being shared by the provider entity and the verification entity when the provider entity has the attribute, each group being authenticated by an authority that stores a group secret key into the entities under its authority, said verification entity being provided with a set of authentication tokens, one for each of the other groups with which the device is intended to communicate, said authentication token comprising at least a random number and a cryptogram of at least this random number by the secret key of each of these other groups; said verification entity comprising calculation means to calculate a certificate from the attribute group arborescence, said certificate being calculated from the authentication tokens of the groups along the arborescence from the attribute verification group's token to the consumer group's token, said verification entity being configured to establish secure channels with the provider entity; said verification entity being further configured to, when a verification is triggered, send the calculated certificate via a secure channel based on the exchange of the cryptograms of the provider group and of the consumer group, said verification entity being further configured to establish an attribute level's secure channel with the verification entity using the decrypted random of the authentication token of the attribute provider group.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

[0068] The following description and the annexed drawings set forth in detail certain illustrative aspects and are indicative of but a few of the various ways in which the principles of the embodiments may be employed. Other advantages and novel features will become apparent from the following detailed description when considered in conjunction with the drawings and the disclosed embodiments are intended to include all such aspects and their equivalents.

[0069] FIG. 1 shows schematically the context and the functioning of Random Handback Authentication (RHA);

[0070] FIG. 2 shows schematically the structure of an authentication token as used in the RHA context;

[0071] FIG. 3 shows an half authentication situation using RHA;

[0072] FIG. 4 shows a recursive authentication standing on two successive levels;

[0073] FIGS. 5A and 5B give two different visual representations of the attribute structures necessary for the implementation of the invention;

[0074] FIG. 6 shows schematically the process of calculation of a certificate of the invention;

[0075] FIG. 7 shows schematically the process of verification of the certificate of the invention;

[0076] FIG. 8 summarizes the principle of an exchange using a certificate according to the invention;

[0077] FIG. 9 schematically shows how an integrity check can be implemented in order to detect attack on the cryptogram;

[0078] FIG. 10 illustrates the attributes' provisioning;

[0079] FIG. 11 schematically shows attributes groups on both sides of a transaction,

[0080] FIG. 12 schematically shows the regeneration of tokens using certificates of the invention;

[0081] FIG. 13 illustrates the viral propagation using the invention;

[0082] FIGS. 14A and 14B show schematically role filtering issues in the context of the invention;

[0083] FIG. 15 shows an additional protection level used to transfer certificate.

DETAILED DESCRIPTION OF EMBODIMENTS OF THE INVENTION

[0084] For a more complete understanding of the invention, the invention will now be described in detail with reference to the accompanying drawing. The same elements have been designated with the same reference numerals in the different drawings. For clarity, only those elements and steps which are useful to the understanding of the present invention have been shown in the drawings and will be described.

[0085] The detailed description will illustrate and describe what is considered as a preferred embodiment of the invention. It should of course be understood that various modifications and changes in form or detail could readily be made without departing from the spirit of the invention. It is therefore intended that the invention may not be limited to the exact form and detail shown and described herein, nor to anything less than the whole of the invention disclosed herein and as claimed hereinafter. Further the features described in the description, the drawing and the claims disclosing the invention may be essential for the invention considered alone or in combination. In particular, any reference signs in the claims shall not be construed as limiting the scope of the invention. The wording “comprising” does not exclude other elements or steps. The wording “a” or “an” does not exclude a plurality.

[0086] On a general point of view, the RHA authentication uses an enciphering algorithm which may be chosen among the available ones. AES algorithms are typically used to calculate the cryptogram according to the RHA principles.

[0087] Advantageously an AES-CBC (Cipher Bloc Enciphering) algorithm as defined in RFC 3602 is used for encrypting/decrypting a message having any length by a secret key. The invention makes use of such an algorithm.

[0088] The invention proposes to generate an RHA certificate which is a combination of algorithm performing a message enciphering as the AES-CBC and the RHA half authentication.

[0089] The AES-CBC is the Cipher Bloc Ciphering of the message M by the key K, noted as followed:

CBC.sub.K.sup.M=AES−CBC[K](M)

[0090] Then the reverse operation is:

M=AES−CBC.sup.-1[K](CBC.sub.K.sup.M)

[0091] The invention is based on the existence of nested groups or, in an equivalent representation, of an arborescence of groups. FIGS. 5A and 5B show such equivalent representations. FIG. 5A shows nested groups G.sub.D and G.sub.C nested in a group G.sub.B itself nested with another group G.sub.E in a group G.sub.A. Group G.sub.E further includes a group G.sub.F. FIG. 5B shows the same groups' structure but as an oriented graph arborescence.

[0092] Let now assume a group G.sub.N having a group key K.sub.GN and the sub-group of G.sub.N as G.sub.N-1.

[0093] According to the preferred implementation of the invention, the certificate M.sub.GN of G.sub.N-1 by G.sub.N is recursively calculated as follows:

M.sub.GN=[ID.sub.GN,C.sub.GN,CBC.sub.R.sub.GN.sup.M.sup.GN)]

[0094] With:

CBC.sub.R.sub.GN.sup.M.sup.GN=AES-CBC[R.sub.GN](CBC.sub.R.sub.GN-1.sup.M.sup.GN-1, ID.sub.GN-1, C.sub.GN,[Additional parameters])

[0095] While using the terminology used in description of FIG. 3, this operation can be done recursively within consumer groups noted G.sub.CX from the lowest group to the highest group, which is the group including all sub-groups, by using the RHA authentication token T.sub.PX from corresponding provider groups noted G.sub.OX. Such consumer groups are the ones to which a verification entity belongs. In the following description of FIGS. 6, 7 and 8, the verification entity is designated by the terms consumer entity as it consumes the authentication tokens of the provider entity to check the belonging of the provider entity to the attribute provider group and to authenticate this belonging. However, it is here noted that this notation is a question of convention as usage of the certificate is symmetric. The relative character of the denomination consumer/provider will appear in the following, a consumer is then a provider in a symmetrical application of the invention. This denomination is indeed relative to the attribute provision/verification.

[0096] The recursive calculation of the certificate according to the invention is schematically shown on FIG. 6 for three levels.

[0097] On FIGS. 6 and 7, C.sub.GPN is the current cryptogram of the RHA Authentication Token of the provider group GPN which will receive the certificate, R.sub.GPN is the current random of the RHA Authentication Token of the group GPN recipient of the certificate, M.sub.GPN is the certificate of the group and ID.sub.GPN is the identifier of the group. C.sub.GPN and R.sub.GPN can be provisioned during prior connection and can be typed for being used only for certificate operations.

[0098] In this last case, any group of any levels will have at least two kinds of tokens: the ones dedicated to one-to-one group authentication and the ones dedicated to certificate authentication.

[0099] As shown on FIG. 6, the lowest level GC-3 on the consumer side, which is the level of the attribute to be checked and so which is the attribute verification group, transmits a certificate M.sub.GP-3 comprising at least a provider group identifier of the lowest level ID.sub.GP-3 and the provider cryptogram of the lowest level C.sub.GP-3 to the next level GC-2.

[0100] The cryptogram C.sub.GP-3 and the group identifier ID.sub.GP-3 are used by the level GC-2, optionally completed with additional parameters AP.sub.-2 to calculate a cipher bloc CBC.sub.R.sub.GP-2 .sup.M.sup.GP-2 using a function CBCF and the random R.sub.Gp-2.Math.of the provider group G.sub.P-2

[0101] Cipher bloc CBC,.sub.R.sub.GP-2 , .sup.M.sup.GP-2 consumer group identifier ID.sub.GP-2 and consumer group cryptogram C.sub.GP-2 forms the certificate M.sub.GP-2 to be transmitted to level GC-1.

[0102] This next level GC-1 adds optionally additional parameters AP-1 to the certificate M.sub.GP-2 before calculating a next cipher bloc CBC.sub.R.sub.GP-2.sup.M.sup.GP-2 using a function CBCF and the provider group random R.sub.GP-1.

[0103] The certificate M.sub.GP-1 is then constituted with this cipher bloc CBC.sub.R.sub.GP-2.sup.M.sup.GP-2, the corresponding provider group identifier ID.sub.GP-1 and the cryptogram C.sub.GP-1 of the current level. It is transmitted to next upper level GC0.

[0104] At this level, which is the highest, additional parameters AP0 are advantageously added to the certificate M.sub.GP-1 before calculating a cipher bloc CBC.sub.R.sub.GP0.sup.M.sup.GP0 using again a function CBCF. Then the provider group identifier ID.sub.GPC0 and the corresponding cryptogram C.sub.GP0 are added to the cipher bloc CBC.sub.R.sub.GP0.sup.M.sup.GP0 to constitute the certificate M.sub.GP0 to be transmitted to a device of the consumer group GP0.

[0105] Then according to the principles of the invention, the provider of the attribute corresponding to the lowest level is here thus on a provider side and can extract from the certificate passed by the upper consumer group the data for performing the certificate decryption and passes the sub-certificate to the sub-group under its control.

[0106] At each level indicated by the successive group identifiers, the provider entity extracts the group identifier of the next addressed group and deduces the key of the group for decrypting the cryptogram and gets the random as the decryption key for the cipher bloc to be decrypted.

[0107] The decryption is performed from the group encapsulating all the others towards the lowest one. The decoding is performed in the opposite direction than the certificate generation from the highest group to the lowest group. The checking of the authenticity of the certificate can be done at each provider group corresponding to a level in the arborescence. It is done by verifying the availability of the sub-group of identifier ID.sub.GPN-1 because the probability to decrypt an available sub-group identifier from a wrong decrypted key R.sub.GPN is highly improbable. It can be further completed by checking an additional parameter noted APX provided by each consumer group GCX and dully decrypted by each counterpart provider group GPX. Typically, integrity can be further controlled using a checksum, a code or a given constant known by the provider side, typically integrated in the certificate as an additional parameter.

[0108] The detailed decryption of the certificate M.sub.GP0 on the provider side is illustrated on FIG. 7. First, the cryptogram C.sub.GP0 is extracted from M.sub.GP0. Using the group key K.sub.GP0, it is decrypted giving R.sub.GP0. The obtained R.sub.GP0 is then used to decrypt the cipher bloc CBC.sub.R.sub.GP0.sup.M.sup.GP0.

[0109] The following formula summarizes this step: CBC.sub.R.sub.GN-1.sup.M.sup.GN-1, ID.sub.GN-1, C.sub.G.sub.N-1, [Additional parametered]=AES−CBC.sup.-1[AES.sup.-1[K.sub.GN](C.sub.G.sub.N)](CBC.sub.R.sub.GN.sup.M.sup.GN) The additional parameters AP.sub.0 are thus extracted as well as ID.sub.GP-1, C.sub.GP-1 and the cipher bloc CBC.sub.R.sub.GP-1.sup.M.sup.GP-1. The three last parameters are then transferred to the group identified by ID.sub.GP-1, they constitute the certificate M.sub.GP-1.

[0110] In group GP-1, the cryptogram C.sub.GP-1 is decrypted using the group key K.sub.GP-1. The obtained random is then used to decrypt the cipher bloc CBC.sub.R.sub.GP.sup.M.sup.GP-1. Here additional parameters AP.sub.-1 for this level GP-1 are extracted as well as ID.sub.GP-2, C.sub.GP-2 and CBC.sub.R.sub.GP-1.sup.M.sup.GP-1 .

[0111] Again the three last parameters are used to generate a new certificate M.sub.GP-2 dedicated to be transferred to the last level GP-2.

[0112] At last, at level GP-2, the cryptogram C.sub.GP-2 is decrypted and the obtained random R.sub.GP-2 is used to decrypt the cipher bloc CBC.sub.R.sub.GP-2.sup.M.sup.GP-2. As no cipher bloc is present, the level GP-2 is informed that it is the lowest level corresponding to the required attribute. It can however receive additional parameters AP.sub.-2 as preceding levels in the certificate.

[0113] By concatenating additional parameters after the parameters mandatory for the invention, each group has the possibility to convey additional information/operations. Typically such additional parameters relate to revocation, addition of groups, transaction parameters . . . Such transaction parameters are, for example, validity checking, payment amount, agency identifier, role . . . The additional parameters added in a certificate shall be chosen in such a way to no disclose any information revealing a possible identity by correlation. Typically large constants should be avoided.

[0114] FIG. 8 summarizes the generation, the transmission and the verification of a certificate in a context where a consumer needs to check that a provider has an attribute. Using the provider side's tokens T.sub.P-2, T.sub.P-1, T.sub.P0 as stored at each level of the consumer's groups, subsequent certificates M.sub.GP-2, M.sub.GP-1, M.sub.GP0 are calculated at each level GC-2, GC-1, GC0.

[0115] An RHA tunnel is then constructed using the consumer's token T.sub.C0 and the provider's token T.sub.P0. It enables the transfer of the certificate M.sub.GP0 of the highest level to the highest provider group GP0. As it has the group key K.sub.GP0 enabling the decoding of the certificate M.sub.GP0, the certificate can be decrypted. A certificate of a lower level M.sub.GP-1 is thus extracted which will be decoded at the level GP-1. This level will at last provide an extracted lowest level certificate M.sub.GP-2 to level GP-2 which is the attribute provider group.

[0116] As soon as the certificate M.sub.GP-2 is decoded, a secure channel can then be established between groups GP-2 and GC-2 using the provider random stored on the consumer side and the random decrypted on the provider side. A new token for this level can thus be provided. For other levels, it is later described how new tokens can be provisioned using the invention.

[0117] For the need of the invention, the AES shall be protected against usual attacks as the Padding Oracle attacks, fault attacks and side Channel attacks.

[0118] The two first groups of attacks can be partially prevented by using a HMAC. Any fault in the AES computation or any bit changed in the C.sub.GN will be detected by the HMAC (HC.sub.GN). The HMAC uses a diversified key KD.sub.GN in order not to disclose any information about the secret key K.sub.GN.

[0119] An illustration of the implementation of a check by HMAC on C.sub.GN is given on FIG. 9. On this figure, it is shown how a received HMAC of C.sub.GN HC.sub.GN is checked in regards with an internally calculated HMAC calculated by the receiving entity for preventing basic attacks as the “Padding Oracle” attack.

[0120] The internal calculation of the HMAC includes a decryption of the received cryptogram C.sub.GN using the group key K.sub.GN, a re-encryption of a new cryptogram C′.sub.GN calculated from the obtained random R.sub.GN using a diversified key KD.sub.GN obtained from group key K.sub.GN. The HMAC properties enable to have a direct check between the recalculated HC′.sub.GN and the received HC.sub.GN.

[0121] Protections against usual attacks (e.g. Padding Oracle attacks) for any intergroup exchanges are advantageously used when an RHA certificate is implemented. As well the AES-CBC shall be protected by the addition of an HMAC.

[0122] The AES protection highlights additional data advantageously added in the certificate or during the establishment of the RHA tunnel for protection of the group secret keys.

[0123] The following table summarizes the comparison between the RHA and the RSA in terms of public/private key definition, certificate, time/count limitation and authentication time.

TABLE-US-00001 Features Support RHA Support RSA Public key Yes IDGROUP, Yes KPU, Module CNGROUP Private key Yes RNGROUP Yes KPR, Module Certificate Yes RHA certificate Yes FIPS 196 Time/count Yes Time/count Yes FIPS 196 limited encrypted in the challenge Authentication NA 100 μs@20 NA 560 ms@20 time MHz- MHz AES 128 bit RSA 2048 bit

[0124] It can be seen that the authentication time can be drastically reduced with the invention.

[0125] The following more precisely discloses the use of the invention in the context of an offline attribute authentication. This context assumes the existence of two main groups: the providers of attributes and the consumer of attributes. Those roles are not fixed and relative to the attribute requester/consumer and the attribute provider.

[0126] Any devices from these groups have subscribed with their respective attributes authority for the installation of an attribute group duly identified and encapsulated into a group controlled by the attributes authority.

[0127] The attributes authority of the provider's side may deny the access of the attributes authority of the consumer's side. Secure channels between both sides can be proprietary or regulated by a standard.

[0128] The two attributes authorities may exchange their respective RHA authentication tokens corresponding to associated attributes which will be provisioned into dully identified groups respective to their association with an attribute, for example blue eyes, birthday, weight, gender, number of children . . . .

[0129] The attribute provisioning is illustrated on FIG. 10. Each consumer and provider side has an attribute authority.

[0130] The attribute authorities AAP and AAC are each provided with attribute identifiers ID.sub.PA and ID.sub.CA and respectively with the authentication token T.sub.CA and T.sub.PA by other attribute authorities.

[0131] On the provider side, the attribute authority AAP has the identifier ID.sub.PA, the token T.sub.CA of the other side and the key K.sub.PA used to calculate the token T.sub.PA sent to the other side. The key K.sub.PA is then the group key for the attribute level group on the provider side. A corresponding nested group is provisioned with this key K.sub.PA associated to the attribute identifier ID.sub.PA and the token T.sub.CA. A new group is thus created on the provider side for the attribute to be managed.

[0132] On the consumer side, the attribute authority AAC has the identifier ID.sub.CA, the token T.sub.PA of the other side and the key K.sub.CA used to calculate the token T.sub.CA sent to the other side. The key K.sub.CA is then the group key for the attribute level group on the consumer side. A corresponding nested group is provisioned with this key K.sub.CA associated to the attribute identifier ID.sub.CA and the token T.sub.PA.

[0133] It can be seen that the attribute group is nested in previous groups on both sides. Then, using the tokens, the attribute groups on both sides are able to establish a secure channel directly as soon as the above levels are previously connected.

[0134] For off-line attributes authentication, the provider and the consumer shall host in their respective secure elements the same hierarchy of groups for accessing an attribute by doing a recursive RHA authentication from the top group up to the attribute group. Such hierarchy is for example of the kind shown on FIGS. 5A and 5B. With this hierarchy, the authentication path is the list of all group identifiers from the root when arborescence is used to structure the hierarchy or from the group encapsulating all the other groups when nested groups are used. Authentication path are given in the table below.

TABLE-US-00002 Group identifier Authentication path G.sub.A G.sub.A G.sub.B G.sub.A.G.sub.B G.sub.C G.sub.A.G.sub.B.G.sub.C G.sub.D G.sub.A.G.sub.B.G.sub.D G.sub.E G.sub.A.G.sub.E G.sub.F G.sub.A.G.sub.E.G.sub.F

[0135] The provider may accept the request or deny it, typically when a negative user's agreement or policy according to an application profile applies. The situation after acceptation of the request is shown on FIG. 11 where successive secure channels are established between successive nested groups to the last one identified by ID.sub.PA and ID.sub.CA and using, respectively key K.sub.PA on the provider side and K.sub.CA on the consumer side. On this figure, two attributes A and B having the same level are shown, for example two vaccination status for a medical application.

[0136] Then, in case the request is accepted, the provider may send a RHA certificate to the consumer. This certificate can be pre-computed. FIG. 12 schematically shows such a reply using a symmetric certificate. Here, even if provider and consumer sides are identified, when the provider answers by sending back a certificate, it is indeed, this time, a consumer in the meaning of the invention. It is here understood that the denomination is relative to the attribute verification and does not refer to technical differences.

[0137] In a preferred implementation, the consumer shall send back the equivalent pre-computed certificate using the same authentication path for regenerating the RHA authentication tokens consumed by the provider certificate.

[0138] In answer to the certificate received from the consumer side, intermediate certificates M.sub.GC-2, M.sub.GC-1 are thus calculated using the consumer tokens as stored on each level of the provider side.

[0139] The secure channel established to transfer the upper level certificate is used to transfer the thus calculated new certificate from the provider side to the consumer side. Certificate decryption is then performed on the consumer side from the upper level to the lowest one. A bidirectional exchange of certificate is thus performed.

[0140] The exchange of certificates shown on FIG. 12 can be used for the regeneration of tokens after certificate decryption. New tokens are calculated on each level on the provider side and these tokens are introduced in the recursive generation of a certificate M.sub.GC0 with calculation similar to the one above described.

[0141] It is here noted that, ideally, the first certificate calculated on the consumer side also includes new authentication tokens for the consumer side to be decrypted and stored on the provider side after use of the previously available and stored authentication tokens.

[0142] Tokens are introduced as additional parameters in a calculation scheme as shown on FIG. 6.

[0143] At each group level, a common session keys (KS-1, KS-2 . . . ) can be computed by using RGN deduced from CGN and the respective group keys. Each level can perform a mutual authentication by exchanging defined information encrypted by the session key for checking the control of respective group keys. As seen above, the additional parameters within the certificate related to each level, may convey the new RHA tokens for a subsequent transaction/connection.

[0144] Any attributes authority may convey within the additional data of the RHA certificate a set of commands for deleting/revoking a group, adding a group, changing a group key, deleting RHA Authentication tokens, adding RHA Authentication Tokens etc.

[0145] The authenticity, integrity and confidentiality of these operations shall be protected in order to avoid deny of services and cannot use secrets within the secure element to update. For these operations, the secure element will use an Asymmetric Encryption as the RSA or the ECC and a public key.

[0146] The certificate can be retrieved from the authority server or during the connection to another secure element by using a principle named viral propagation described in the previously filed RHA authentication patent application. According to this viral propagation, operations encapsulated by attributes authorities into a certificate can be propagated from secure elements of the provider/consumer side by using the secure elements of consumer/provider side. The encapsulated operations dully tagged can be append to the additional data of any certificates and propagated to secure element having no connectivity means. The propagation can be limited in time of an hop count.

[0147] FIG. 13 illustrates this viral propagation where additional parameters are transferred from the attribute authority once to a secure element SEPA. This secure element then connects with a consumer side secure element SECA which itself connects later with a provider secure element SEPB. This provider secure element is thus provided with the additional parameters. This figure only shows a linear propagation but, as soon as, the secure element SECA can connect to many other provider secure element, this principle is rapidly growing leading to a viral always faster propagation.

[0148] The invention also enables to control the life cycle of the secure element including groups' ownership. Indeed, the SE has a single group at the initialization controlled by the SE maker. The subsequent groups are joined by using the principle related to the Addition & Revocation of groups as explained earlier.

[0149] The invention further enables to do indirect disclosure of attributes. All attributes have a group identifier. Then the availability of the group shall not indeed disclose any information about the availability of the attribute. The connection of a provider attribute group with a consumer attribute group can only express the availability of the attribute.

[0150] The non connection to a consumer attribute group from a provider attribute group can express the non availability of the attribute or the non acceptance to disclose an available attribute, for example if the user does not agree to disclose it or in respect of a policy.

[0151] By completing the RHA certificate protocol between two groups sharing the same attribute on the provider and consumer sides, then the provider brings the evidence about the authenticity of an attribute related to the authentication path involved in the recursive authentication.

[0152] It is here noted that a same attribute on a user point of view, for example the gender male/female, can be present in several arborescences. In this case corresponding groups in arborescences will have different attribute identifiers and different corresponding keys according to the RHA principles. The same attribute may thus have different authentication paths to be checked.

[0153] Besides the attribute identifier is unique or not ambiguous in the scope of an application and enables the attribute provider group to accept or deny a request of attribute provision. The acceptation or deny is advantageously decided in relation with a user's agreement or policy according to an application profile.

[0154] The Attribute authority may filter the consumers for conditionally granting the access to an attribute. This is illustrated on FIGS. 14A and 14B.

[0155] On both figures is shown the arborescence as known on the provider side, which is a provider P, typically a user device, and respectively, on FIG. 14A, the arborescence as known by a consumer C, which is here a policeman secure element, and on FIG. 14B, the arborescence as known by a consumer C which is here a nurse. The nurse will be able to check only if the user has allergies with the allergies attribute A while the policeman will be able to check the gun license attribute GL and the driver license attribute DL.

[0156] The arborescence comprises a common authority, which is for example a government G, having defined consumer group C and provider group P. The consumer C secure element of the user comprises a provider entity belonging to a plurality of groups enabling to discuss with a consumer corresponding group. In the example of FIG. 14A and 14B, the provider entity belongs to the group of the university attribute U, the group of the minister attribute M, the group of the policeman attribute P, the group of the allergia attribute A, the group of the gun license GL and the group of the driver license DL.

[0157] As shown on FIG. 14A, the secure element of the policeman schematically represented on the right side, comprises a verification entity belonging only to a certain number of groups as listed above for the user's secure element. It thus belongs to the minister attribute M, the policeman attribute P, the gun license attribute GL and the driver license attribute DL.

[0158] On FIG. 14B, it can be seen that the nurse secure element has a verification entity belonging to the minister attribute M, the nurse attribute N and the allergia attribute A. With the invention, this secure element will be able to verify quickly the belonging of the provider entity of any other secure element to these attribute only. It is here noted that a same attribute for the user, for example the driving license attribute, can appear in the attributes that can be controlled by the nurse and in the attribute that can be controlled by the policeman. In this case distinct identifier will be advantageously used. However, as the attribute group is indeed under the nurse group or under the policeman group, the identification will anyhow be distinct.

[0159] The invention being based on the arborescence of groups enables to filter the role of the entities, in particular here of the verification entities.

[0160] Of course the provider can bring the exportable proof of the authentication via a RHA certificate which may seal some transaction parameters (date, amount, operations . . . ). The said exportable RHA certificate may be obtained without the authentication of the consumer and the checking can be delegated to a qualified server.

[0161] The solution is faster than the one using a PKI and there are no shared keys between the providers and the consumers of the attributes. Never large constants are exchanged between groups preventing the correlation of groups and disclosing of identities.

[0162] If needed the forward secrecy can be ensured with the invention by negotiating a session key for performing a tunnel (AES-CBC) between the attributes consumer and the attributes providers. The said session key may use a Diffie-Hellman Tunnel based on random seeds within an initial RHA tunnel. The combination of both ensures no man-in-the-middle attack and the forward secrecy due to the complexity to resolve large discrete logarithms.

[0163] This feature is illustrated on FIG. 15 where a Diffie-Hellman tunnel is built inside the RHA tunnel before communicating the certificate MC0. It is here noted that the certificate's circulation, typically an answer to a previously transferred certificate, is shown symmetric to the one shown on FIG. 8, illustrating the relativity of the denomination provider/consumer.

[0164] The invention necessitates however an enlarged management of secret group keys for the consumer group and for the provider group where, with a solution based on a PKI, only the provider group manages private keys.

[0165] This is advantageous when attributes authorities want to control who can consume the attributes.

[0166] The consumer can forge a valid consumer certificate but cannot transfer the said certificate to another consumer because the RHA tunnel for transferring a certificate is valid between the provider group and the consumer group. The certificates are only useable from consumers to providers or providers to consumers but not providers to providers or consumers to consumers.

[0167] In the above 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 above 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.