Patent Application
20250038979
The present invention relates to the technical field of electronic authentication and attestation. One or more embodiments of the invention relate generally to the field of cryptographic authentication. More particularly, embodiments relate to a method and system for proof of attestation.
It relates to a new and developed way to verify and attest the authenticity of personal documents issued by an attribute provider to an independent service provider where there is no chain of trust there between.
The invention envisages a means of allaying trust concerns regarding authenticity of documents privately attested to. Advantageously, the invention provides a technical mechanism for endorsement of attestations to users wanting to enhance the trust in their private attestations.
Authentication is the security process of verifying a user's identity with the system that authorizes the individual to access the system, for example, a sign-on process. Authentication is important because it assigns responsibility to the user for entries he or she creates, modifies, or views. Authorship is attributing the origination or creation of a particular unit of information to a specific individual or entity acting at a particular time.
Attestation is the act of witnessing the signing of a formal document and then also signing it to verify that it was properly signed by those bound by its contents. Attestation is a legal acknowledgment of the authenticity of a document and a verification that proper processes were followed. Attestation can also be the act of applying an electronic signature to the content, showing authorship and legal responsibility for a particular unit of information. An electronic signature is a generic, technology-neutral term for the various ways that an electronic record can be signed, and attested.
The problem: Digital attestations (e.g. diploma, credentials, etc.) from Private Attribute Providers (e.g., academics, corporate, association, etc.) are generally considered dubious even if delivered by formal or official means. They provide only a variable level of confidence, and are not bound to a master list or trust list. Many time the Private Attribute Provider is an unknown issuing authority from the viewpoint of a relying party. Such a private attestation, if delivered by the user alone to a relying party, would not be trustworthy, because the user could alter it, or it could be a forged copy. Thus, when a relying party requires a user to present a digital attestation issued by a Private Attribute Provider (e.g. academic institution), they would like to be certain that digital attestation belongs to the user presenting it, and have confirmed its authenticity by a trusted source.
Presently, organizations must access individual resources to review existing information specific to e-signatures, attestation, and authorship of user documents. Such types of proofing is a costly and time consuming exercise. And, especially those related to user identification, where privacy concerns of sharing user information and personal data are at issue. No common system holds all identity information for an individual user. And, there is no single overwhelmingly accepted standard, law, or regulation for device attestation of a user's identity.
Although, certain specifications (GP, ISO, ETSI, CEN/CENELEC, W3C, GSMA) promulgate abstract ideas for certifying and trusting digital user-identification documents they do not provide concrete implementations. To this point, ISO/IEC 18013-5 proposes standardized methods of interacting with a mobile ID (mID) and mobile driver's license (mDL) for identity and driving privilege use cases. An open mDL/mID ecosystem that conforms with the global interoperability standards provides a level of trust comparable to a traditional passport or user identification. Although the ISO/IEC 18013-5 draft international mDL standard seeks to provide mechanisms for obtaining and trusting identity document data from a mobile driver's license, the specifications are complex and silent on implementation specifics.
The problem with these standards proposals is that they do not provide implementations for endorsement of digital attestations from Private Attribute Providers. Such ID proofing is timely and costly; a Relying Party has generally too few benefits in checking complex credentials on its own. Moreover, Government or public authorities are reluctant to consent to providing more data than their insurance liability allows for when requested to confirm digital credentials.
The invention provides a solution that overcomes existing limitations and advantageously provides for closer involvement of Private Attribute Providers and Private Service Providers in a cryptographic ecosystem, where users are looking to enhance the trust in their private attestations, for example, by way of a connected device.
In a first embodiment, a method for non-repudiable endorsement of a private attestation is provided. The method includes the steps of receiving an Attestation from a Private Attribute Provider (PAP), wherein the Attestation includes attributes with corresponding attribute names and values, and an optional PAP signature signed by the PAP, and is further characterized by:
The two bindings above provide for stronger trust enhancements over the state of the art. The step of binding a user of a connected device to the Attestation includes collecting a set of user certified attribute names from said attributes selected by the user, authenticating the user to an Issuing Authority, generating a key pair for the user, comprising a public key (PuK) and a private key (PrK), and transmitting said public key (Puk) to said Issuing Authority. The step of binding pivotal attributes to equivalent attributes of the Issuing Authority includes requesting the Issuing Authority to authorize user and endorse said Attestation based on it, and validating said set of user certified attribute names. If validated, the method includes receiving from said Issuing Authority a signed Server Proof, aggregating the signed Server Proof with a Verifier Challenge to produce a Verifier Blob, signing the Verifier Blob with said private key (PrK) to produce a Mobile Signed Blob, packaging the Attestation with the Mobile Signed Blob to produce an Endorsed Attestation, and then presenting said Endorsed Attestation to said Verifier to access a service offered by said Verifier. For said step of binding pivotal attributes, the Issuing Authority performs steps of: checking a validity of said set of user certified attribute names against equivalent corresponding attribute values, and, if valid, endorsing said Attestation alongside said set of user certified attribute names and a hashed Attestation and a hashed Public key; and, returning said signed Server Proof; otherwise, if not valid, not endorsing said Attestation.
The step of endorsing includes signing the Server Proof to produce said signed Server Proof, said signed Server Proof comprising said hashed Attestation, a hash of said user certified attribute names, an Issuing Authority Challenge, and said hashed Public Key. The Endorsed Attestation comprises: said Attestation and said optional PAP signature; and said Mobile Signed Blob comprising: a connected device signature over said Verifier Blob using private key (PrK); and said Verifier Blob. The Verifier Blob comprises said Verifier Challenge; and said signed Server Proof. The signed server proof comprises said hashed Attestation, said hash of said user certified attribute names, said Issuing Authority Challenge, said hashed Public Key, and an Issuing Authority signature. The step of checking a validity includes authenticating said user certified attribute names to a civil registry, an identification documents registry, an administrative registry or any source of prior registered information for connected device authentication of a user of said connected device. The access to said service grants a right or privilege to a user of a device holding said device key.
The Attestation can further include a purpose for using said attributes that limits said access by said PAP, where the purpose in said Attestation contains terms of usage, an expiry date, or other conditional measure for using the Endorsed Attestation. Terms of usage, an expiry date, or other conditional measure can be included in said Issuing Authority Challenge to limit use of the Endorsed Attestation by said Issuing Authority. Endorsing said Attestation alongside said set of user certified attribute names and a hashed Attestation and a hashed Public key binds the user to said key pair of the connected device, thereby preventing the user from denying the connected device signature.
In a second embodiment, a method for non-repudiable pre-endorsement of a private attestation by way of a connected device is provided. The method includes the steps of receiving an Attestation from a Private Attribute Provider (PAP), wherein the Attestation includes attributes, corresponding attribute names and values, and a PAP Challenge, and is further characterized by: 1) binding a user of the connected device to the Attestation, and 2) binding pivotal attributes to equivalent attributes of an Issuing Authority. The step of binding a user of the connected device to the Attestation includes collecting a set of user certified attribute names from said attributes selected by the user, authenticating the user to the Issuing Authority, generating a key pair for the user, comprising a public key (PuK) and a private key (PrK), and transmitting said public key (Puk) to said Issuing Authority. The step of binding pivotal attributes to equivalent attributes of an Issuing Authority includes requesting the Issuing Authority for its authorization to endorse said Attestation based on it, validating said set of user certified attribute names.
If validated, the method further includes receiving from said Issuing Authority a signed Server Proof, aggregating the signed Server Proof with the PAP Challenge to produce a pre-endorsed Blob, signing the pre-endorsed Blob with said private key to produce a Mobile Signed pre-endorsed Blob, and presenting said Mobile Signed pre-endorsed Blob to said PAP for authentication. If authentication is successful, the method includes receiving a PAP signed Attestation, and re-building an Endorsed Attestation with a Verifier Challenge. The step of re-building an Endorsed Attestation comprises aggregating the signed Server Proof with said Verifier Challenge to produce a Verifier Blob, signing the Verifier Blob with said private key (PrK) to produce a Mobile Signed Blob, packaging the PAP signed Attestation with the Mobile Signed Blob to produce an Endorsed Attestation; and presenting said Endorsed Attestation to said Verifier to access a service offered by said Verifier.
In a third embodiment, a system for non-repudiable endorsement of a private attestation is provided. The system includes an Issuing Authority, a Verifier; and a Private Attribute Provider (PAP) to provide an Attestation comprising attributes and corresponding attribute values. A connected device operated by a user is further characterized in that it binds the user to the Attestation, and binds pivotal attributes to equivalent attributes of said Issuing Authority. Responsive to said bindings, it aggregates a signed Server Proof received from said Issuing Authority with a Verifier Challenge from said Verifier to produce a Verifier Blob, signs the Verifier Blob to produce a Mobile Signed Blob, packages the Attestation with the Mobile Signed Blob to produce an Endorsed Attestation, and presents said Endorsed Attestation to said Verifier to access a service offered by said Verifier. The connected device binds the user to the Attestation by collecting a set of user certified attribute names, but not attribute values, from said attributes selected by the user, authenticating the user to the Issuing Authority, generating a key pair for the user, comprising a public key (PuK) and a private key (PrK), and transmitting said public key (Puk) to said Issuing Authority.
The connected device binds pivotal attributes to equivalent attributes of said Issuing Authority by requesting the Issuing Authority for its authorization to endorse said Attestation based on it validating said set of user certified attribute names, and if validated, receiving from said Issuing Authority said signed Server Proof. The Issuing Authority checks a validity of said set of user certified attribute names to its own corresponding attribute values, and if valid, endorses said Attestation alongside said set of user certified attribute names and a hashed Attestation and a hashed Public key; and returns said signed Server Proof; otherwise, if not valid, it does not endorse said Attestation. The Issuing Authority signs the Server Proof to produce said signed Server Proof, said signed Server Proof comprising said hashed Attestation, a hash of said user certified attribute names, an Issuing Authority Challenge, and said hashed Public Key.
In a fourth embodiment a connected device for non-repudiable endorsement of a private attestation is provided. The device includes a power supply to provide power; a memory to store instructions and data; a communication module to transmit and receive data; a display to present information and receive user input; and a processor to run a computer program. The computer program comprises a non-transitory computer readable medium storing program code to be executed by at least one computer processing unit (CPU) in a computational environment, whereby execution of the program code causes the at least one CPU to perform operations of the methods above. In one arrangement the method includes receiving an Attestation from a Private Attribute Provider (PAP), wherein the Attestation includes attributes and corresponding attribute values; and, is further characterized by binding a user of the connected device to the Attestation, and binding pivotal attributes of said attributes to equivalent attributes of an Issuing Authority.
The system provided herein is designed in a way to be compatible with electronic identification and trust services for electronic transactions (eIDAS2) regulation. For instance, by introducing a role called ‘Gov Server’ that is enacted by eIDAS Qualified Trust Service Provider (TSP), the system applies to the eIDAS2 context and may comply with the regulation. Through this practice, users can ask a TSP to provide them a QEAA (qualified attestation of attributes) that will serve to endorse private attestations delivered by any private attribute provider. In this arrangement, the TSP signs the compound (e.g. attributes, attestation, proof, etc.) called ‘Signed Gov Proof’. In this manner the private attestation can be endorsed by a TSP, except by validating EAA in QEAA (Qualified/Electronic Attestation of Attributes), to offer a solid way to achieve the bridge between private and public attestations, while preserving privacy.
The features of the present invention, which are believed to be novel, are set forth with particularity in the appended claims. The invention, together with further objects and advantages thereof, may best be understood by reference to the following description, taken in conjunction with the accompanying drawings, in the several figures of which like reference numerals identify like elements, and in which:
While the specification concludes with claims defining the features of the invention that are regarded as novel, it is believed that the invention will be better understood from a consideration of the following description in conjunction with the drawing figures, in which like reference numerals are carried forward.
In computing, an attribute is a specification that defines a property of an object, element, or file. It may also refer to or set the specific value for a given instance of such. In many object-oriented languages, certain attributes can also be declared as private, making it difficult, if no impossible, for users of a class to directly view or modify their values. The developer of the class then provides methods to control the ways in which these attributes can be manipulated or used. The protocol herein described for endorsing a private attestation can be employed by the user to endorse a signed attestation with attributes of his or her choice. It can also be requested by Private Attribute Providers before they apply their signature onto an attestation.
There is a need to endorse attributes from Private Attribute Provider(s) with two strong enhancements: 1) binding with the holder, and 2) binding with certified pivotal attributes from an Issuing Authority. Identification proofing is costly and a Relying Party placed in such a positon receives little benefit from checking complex credentials on its own. Moreover, when a third party such as a government public authority, is included as a trusted source to assist with the proofing, the contractual liability generally presents a challenge; it is difficult to obtain consent and delivery of data responsive to a request for endorsement of digital credentials. The embodiments herein provides a solution that overcomes these limitations.
Referring to
The Issuing Authority, by means described herein, endorse the private attestation to produce an endorsed private attestation. The endorsement assures the Service Provider that the private attestation 111 is authentic and trustworthy. The user then presents endorsed private attestation to the Service Provider 130 as a condition to receive the service 151. Access to the service 151 grants a right or privilege to a user of a mobile device holding a device key.
The use-case diagram 100 exemplifies a general high-level method (steps 141-146) for non-repudiable endorsement of private attestations, as a solution for users to strengthen the level of confidence in user's private attestations before delivery to a Service Provider 130 (or Relying Party). It introduces the Issuing Authority 120 to the user and the service provider as a trusted source and intermediary for the endorsement. In this use-case, the Service Provider 130 asks the user for digital attestation issued by the Private Attribute Provider and receives assurance by way of the endorsed attestation from the Issuing Authority, that the digital document it received belongs to the user and that main (pivotal) user ID attributes featured by the attestation were verified and validated.
For example, consider that the user is a former student that graduated from an academic institution (e.g. PAP 110) and seeks a privilege from an alumni association (e.g. Service Provider 130). The user obtains a digital diploma document with associated user-identifying information from the PAP 110, which granted the degree to the user, and where the degree states the user's name, graduation date, granting institution, and discipline area. In this example, the Service Provider 130 is the alumni association that can grant a privilege (e.g. service 151) to the user but requires the user to have attended and received a diploma from the institution in order to receive service, or the privileges; that is, conditions to the service. The Service Provider 130 could also be a 3rd party Verifier working on behalf of the alumni association to authorize users. Although the user could have a copy of the diploma, or even a picture of the diploma (actual, or on a mobile device) to present to the alumni association as proof, it would impose a time and cost effort on the association (or 3rd party affiliate) to confirm the authenticity of the diploma (copy or picture). It would be preferable if the diploma was received directly from the degree granting institution because it is a more trustworthy source than the user alone. But again, this imposes a burden on both the PAP (e.g. academic institution) and the Service Provider (e.g., alumni association) to communicate and establish a basis of trust.
In this example, at step 141 the user requests a user-identifying digital document, to which the PAP 110 responds at step 142 with a private attestation 111; namely, proof that the digital document it provided is indeed true and authentic. It attests to the private information in the digital document. The user at this point could then present the private attestation. Another configuration of the use-case 100 discussed ahead, provides a solution for Private Attribute Providers (PAP) to require pre-endorsement to reduce risk of ‘wrong deliveries’ of attestations.
However, as previously mentioned, there is a need to endorse the attestation from a reliable source other than the user. An endorsement is an approval, similar to a digital certificate to prove authenticity of something. To provide this assurance, the user at step 143 authenticates to the Issuing Authority 120, and upon authentication, selects pivotal attributes (e.g. first name, last name, birth date, place of birth) in the private attestation 111 for the Issuing Authority 120 for it to independently validate against. The Issuing Authority at step 144, upon validating the pivotal attributes, responds with Server Proof; namely, that the private attestation corresponds to the user. At step 145, the Server Proof is combined with the Private Attestation to produce the endorsed private attestation 400. At step 146, the user presents the endorsed private attestation to the Service Provider 130 to receive the service 151.
Referring to
The method 200 can start at step 201, wherein a user requests from their connected device 100, an (private) attestation from the PAP 110. The user collects the attestation from the PAP. In this example, the attestation asserts a graduation granted to Mr John Smith born on Oct. 23, 1980 in Utopia. The PAP controls the ways in which the private attributes can be attested. For instance, an academic institution is a PAP that can attest a particular degree was granted to a particular student on a particular date. A corporation that provides user identification badges (IDs) is another example of a PAP that can attest that a particular badge was given to a particular employee for entry into certain areas, or access to certain computer systems, for a certain time period. An association that provides access to services to registered users is another example of a PAP that can provide attestation services.
At step 202, the PAP responds with the attestation, and the connected device 100 then stores the attestation. The Attestation includes attributes with corresponding attribute values. In the example user-case of
At step 206, the mobile device presents to the user a list of attribute names in the Attestation and prompts the user to select a subset of attribute names, but not values, to preserve privacy. This is the set of user certified attribute names; also, considered “pivotal” attributes. Briefly referring to
At step 208, the user then authenticates to the Issuing Authority 120 by way of their connected device 100. From his or her mobile, the user authenticates to an Issuing Authority 120, for example, a Government Server (e.g. login/pass or additional authentication vector or eIDCard, or OOB pre-acquired secret etc.). During this step, with their mobile, the user generates a key pair <User Public Key (Puk) and User Private Key (PrK)> and sends a request to the Government Server for an authorization to endorse the attestation alongside the set of pivotal attribute names {e.g., first_name, last_name, birthdate, place_of_birth}, a hash of the attestation (attestation not revealed in clear for privacyreasons) and a hash of user public key (HPuK). The step of endorsing the Attestation alongside the set of user certified attribute names and a hashed Attestation and a hashed Public key binds the user to the generated key pair of the mobile device, thereby preventing the user from denying his or her endorsement (and mobile device signature) of the attestation.
At step 210, the Issuing Authority 120 1) fetches User Attributes, 2) Hashes the User Attributes, 3) signs a token as server proof, and 4) records a {Hash (PAP.Attestation)+UID+Hash of Use Attributes}. Specifically, the Issuing Authority 120 independently validates the pivotal attribute names, and it does so against attribute values it has already from the authorization of the user, or finds through its own search of trusted sources. Validating pivotal attributes to equivalent attributes of the Issuing Authority is a proofing exercise. It is one component of the server proof. Once the Issuing Server 120 obtains its own independent attribute values for the selected pivotal attribute names, it will examine the attestation to ensure corresponding attribute name and value pairs are consistent; namely, that the attribute values for the names in the attestation are correct in view of its own investigation/search. For example, the Government Server checks the validity of the attributes in the Attestation for the authenticated user to see that the attribute name/value pairs match against attribute name/value pairs from within a Civil Registry, Identification documents Registry, Administrative Registry, etc.
At step 212, the Issuing Authority 120 returns signed Server Proof if the resulting matching exercise from its investigation was successful. For example, a government server will return a signed Gov server proof if the checking is successful; the proof comprising the hash of the attributes, a challenge (or unique identifier UID) and the hashed attestation. At step 214, the mobile device stores the signed Server Proof for later use. At this point the user has the Server Proof it will need to satisfy a Verifier request for user identification. It can terminate communication with the Issuing Authority 120. The user now proceeds to communicate with the Verifier 130.
At step 216, the user requests access to a service provided by the Verifier (or Source Provider or Relying Party). In the continuing example, the service could be an alumni privilege for those students who went to a particular academic institution. The user logs into the Verifier service with his mobile device, and requests service. The Verifier 130 responds with a Verifier Challenge at step 218 which is provided to the user's mobile device. At this point, the user will prompt its mobile device to generate an endorsed attestation as shown by step 220. The connected device 100 under the user's direction aggregates the Gov server proof with the Verifier challenge from the Verifier/SP/RP, then signs the entire package (with his device key-User Private Key, PrK), thereby generating an endorsed attestation. A detailed description of an exemplary endorsed attestation 400 is shown and provided in
Upon the mobile device generating the endorsed attestation 400, the user sends it to the Verifier 130 at step 222. That is, the user delivers the endorsed attestation to the Verifier/SP/RP to access a service or be granted a right, etc., for example, alumni webpage access rights. The Verifier 130 checks the payload of the endorsed attestation 400 (see
Referring to
The Attestation 300 includes a purpose for using each attribute, for example, terms of usage, an expiry date, or other conditional measure for using the Endorsed Attestation 400. The purpose may be provided by the PAP 110 or the User. The Attestation 300 includes a signature 304 confirming it was signed by the PAP. But, it is optional in that the PAP signature 304 accompanies the Attestation 400 if deemed a pre-requisite to the Issuing Authority endorsing the attestation 300.
The Mobile Signed Blob 320 comprises a Verifier Blob 340 and a mobile signature 322 (shown as a key). The mobile signature 322 is created by the connected device 100 (See
Briefly,
Referring now to
Bindings 407-408 bind the user of the connected device 100 to the Attestation 300, thereby creating a non-repudiation path whereby the user can not deny it selected the pivotal attributes used by the Issuing Authority to endorse the Attestation requested by the user, or deny that it did not create the Verifier Blob 340 for requesting a service from the Verifier 130. The binding path 407 occurs when the user's mobile device signs the Verifier Blob 340 with the User's Private Key (PrK) to produce the Mobile Signed Blob 320. The binding path 408 occurs when the user provides to the Issuing Authority its User's Public Key (PuK) and requests authentication and endorsement to the Attestation 300. The binding 388 is not repudiable because the hashed User Public Key (PuK) 373 is embedded within the signed Server Proof 360. Binding path 409 binds the user to a Verifier 130 when mobile device builds the Endorsed Attestation 400 specific to a challenge provided by the Verifier (or Source Provider, or Relying Party).
Referring now to
The binding point 424 commits the user to replay the Server Proof only for the same Attestation. Point 425 binds the user to the authorization from the Issuing Server. This binding, similar to the purposes field in the attestion, can comprise properties or terms of usage established by the Issuing Authority: an expiry date or other conditions for using the Server Proof. Binding point 426 binds the user to the User Private Key (PrK) created and stored on the mobile device by the user. Accordingly, the user cannot deny the signature, because the signed Server Proof includes a copy of the corresponding User Public Key (Puk).
The binding point 427 establishes a uniqueness to the selected Verifier and binds the Endorsed Attestation to that particular Verifier. Because the inclusion of the Verifier Challenge 342 within the Verifier Blob 340 is under the control of the user and their connected device 100, the user can thus create other Endorsed Attestations specific to other Verifiers; namely by embedding their Verifier Challenge 342 into the Verifier Blob 340 and signing the package with the User Private Key (PrK) of the mobile device thereby producing a Mobile Signed Blob 320 specific to a Verifier. This configuration ability to include a Verifier Challenge 342 in the Mobile Signed Blob is what allows for an “endorse once and use many” approach. Although the user can reuse the signed Server Proof, the can do some only by using the same Attestation.
Referring to
In method 500, at step 502 the user requests a service from Verifier 130. At step 504 the Verifier 130 returns with a Verifier Challenge. At step 506, the user, by way of the connected device 100, generates an endorsed attestation 400 in a manner similar to the steps and explanation shown in
At step 508 the user presents the endorsed attestation to the Verifier 130. The Verifier at step 510 checks the package for its contents and correctness (checks user signatures and attributes) and decides what service to offer at step 512, at which time it OK's and authorizes access to the service; namely, after ensuring the provided Attestation matches the Server Proof. This allows the user to reuse the same Server Proof from the Government Server with several different Verifiers (Service Providers or Relying Parties). Notably, only the Verifier/RP's challenge binds the user to a Verifier/RP. Accordingly, the Government Server proof can be reused with several Verifiers/RP provided its terms of usage authorize it.
Referring to
At step 602, the user submits a request for the attestation (e.g. diploma) to the PAP 110. It receives the Attestation from a Private Attribute Provider (PAP), wherein the Attestation includes attributes, corresponding attribute values, and a PAP Challenge 604. At step 606 the PAP 110 however requests a pre-endorsement before it will add its signature 388 to the attestation. Notably, the unsigned attestation 299 returned by the PAP 110 at step 606 does not include a signature. Rather, it includes a PAP challenge 604 as a signaling for a pre-endorsement. So, the user cannot proceed to use the attestation 299 as was done in method 200, because the PAP signature is absent at this step 606. Note, it is a “non-signed” attestation at this point.
As was done in method 200, the method 600 here similarly includes binding a user of the mobile device to the Attestation. Thus, similarly, the user must first select a set of user certified attribute names (the pivotal attributes), but not attribute values, from the attributes identified in the unsigned attestation 299. The user authenticates to the Issuing Authority 120 (see
At step 612, the PAP authenticates the pre-endorsed data package, by checking the signatures and hashed attributes of the Mobile Signed pre-endorsed Blob (similar to the endorsed attestation 400 but includes a PAP challenge 604 instead of a Verifier Challenge 342). If authenticated, the PAP sends at step 614 a PAP signed Attestation that includes the PAP signature 388, and that is received by the connected device 100. Note, the attestation is now “signed”. At this juncture the attestation 300 is the same form of that in method 200 in
Advantages provided by the embodiments herein, include, but are not limited to: For the users:
In one embodiment, a system for non-repudiable endorsement of a private attestation is provided. The system includes an Issuing Authority, a Verifier, a Private Attribute Provider (PAP), and a mobile device. The PAP provides an Attestation comprising attributes and corresponding attribute values. The mobile device operated by a user binds the user to the Attestation, and binds pivotal attributes to equivalent attributes of said Issuing Authority. Responsive to said bindings, the mobile device aggregates a signed Server Proof received from said Issuing Authority with a Verifier Challenge from said Verifier to produce a Verifier Blob, signs the Verifier Blob to produce a Mobile Signed Blob, packages the Attestation with the Mobile Signed Blob to produce an Endorsed Attestation, and presents said Endorsed Attestation to said Verifier to access a service offered by said Verifier.
The mobile device binds the user to the Attestation by collecting a set of user certified attribute names, but not attribute values, from said attributes selected by the user. It authenticates the user to the Issuing Authority, generates a key pair for the user, comprising a public key (PuK) and a private key (PrK), and transmits said public key (PuK) to said Issuing Authority. The mobile device binds pivotal attributes to equivalent attributes of said Issuing Authority by requesting the Issuing Authority for its authorization to endorse said Attestation based on it, and validating said set of user certified attribute names. If validated, it receives from said Issuing Authority said signed Server Proof.
The Issuing Authority checks a validity of said set of user certified attribute names to its own corresponding attribute values, and, if valid, endorses said Attestation alongside said set of user certified attribute names and a hashed Attestation and a hashed Public key. It returns said signed Server Proof; otherwise, if not valid, it does not endorse said Attestation. The Issuing Authority signs the Server Proof to produce said signed Server Proof, said signed Server Proof comprising said hashed Attestation, a hash of said user certified attribute names, an Issuing Authority Challenge, and said hashed Public Key.
The machine may comprise a server computer, a client user computer, a personal computer (PC), a tablet PC, a laptop computer, a desktop computer, a mobile device, a cell phone, a control system, a network router, switch or bridge, or any machine capable of executing a set of instructions (sequential or otherwise) that specify actions to be taken by that machine. It will be understood that a device of the present disclosure includes broadly any electronic device that provides voice, video or data communication. Further, while a single machine is illustrated, the term “machine” shall also be taken to include any collection of machines that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methodologies discussed herein.
The computer system 700 may include a processor 702 (e.g., a central processing unit (CPU), a graphics processing unit (GPU, or both), a main memory 704 and a static memory 706, which communicate with each other via a bus 708. The computer system 700 may further include a video display unit 710 (e.g., a liquid crystal display or LCD), a flat panel, a solid state display, or a cathode ray tube (CRT)). The computer system 700 may include an input device 712 (e.g., a keyboard, touchless sensing unit 110), a cursor control device 714 (e.g., a mouse, touchless sensing unit 110), a disk drive unit 716, a signal generation device 718 (e.g., a speaker or remote control) and a network interface device 720.
The disk drive unit 716 may include a machine-readable medium 722 on which is stored one or more sets of instructions (e.g., software 724) embodying any one or more of the methodologies or functions described herein, including those methods illustrated above. The instructions 724 may also reside, completely or at least partially, within the main memory 704, the static memory 706, and/or within the processor 702 during execution thereof by the computer system 700. The main memory 704 and the processor 702 also may constitute machine-readable media.
Dedicated hardware implementations including, but not limited to, application specific integrated circuits, programmable logic arrays and other hardware devices can likewise be constructed to implement the methods described herein. Applications that may include the apparatus and systems of various embodiments broadly include a variety of electronic and computer systems. Some embodiments implement functions in two or more specific interconnected hardware modules or devices with related control and data signals communicated between and through the modules, or as portions of an application-specific integrated circuit. Thus, the example system is applicable to software, firmware, and hardware implementations.
In accordance with various embodiments of the present disclosure, the methods described herein are intended for operation as software programs running on a computer processor. Furthermore, software implementations can include, but not limited to, distributed processing or component/object distributed processing, parallel processing, or virtual machine processing can also be constructed to implement the methods described herein.
While the machine-readable medium 722 is shown in an example embodiment to be a single medium, the term “machine-readable medium” should be taken to include a single medium or multiple media (e.g., a centralized or distributed database, and/or associated caches and servers) that store the one or more sets of instructions. The term “machine-readable medium” shall also be taken to include any medium that is capable of storing, encoding or carrying a set of instructions for execution by the machine and that cause the machine to perform any one or more of the methodologies of the present disclosure.
The term “machine-readable medium” shall accordingly be taken to include, but not be limited to: solid-state memories such as a memory card or other package that houses one or more read-only (non-volatile) memories, random access memories, or other re-writable (volatile) memories; magneto-optical or optical medium such as a disk or tape; and carrier wave signals such as a signal embodying computer instructions in a transmission medium; and/or a digital file attachment to e-mail or other self-contained information archive or set of archives is considered a distribution medium equivalent to a tangible storage medium. Accordingly, the disclosure is considered to include any one or more of a machine-readable medium or a distribution medium, as listed herein and including art-recognized equivalents and successor media, in which the software implementations herein are stored.
The illustrations of embodiments described herein are intended to provide a general understanding of the structure of various embodiments, and they are not intended to serve as a complete description of all the elements and features of apparatus and systems that might make use of the structures described herein. Many other embodiments will be apparent to those of skill in the art upon reviewing the above description. Other embodiments may be utilized and derived therefrom, such that structural and logical substitutions and changes may be made without departing from the scope of this disclosure. Figures are also merely representational and may not be drawn to scale. Certain proportions thereof may be exaggerated, while others may be minimized. Accordingly, the specification and drawings are to be regarded in an illustrative rather than a restrictive sense.
Such embodiments of the inventive subject matter may be referred to herein, individually and/or collectively, by the term “invention” merely for convenience and without intending to voluntarily limit the scope of this application to any single invention or inventive concept if more than one is in fact disclosed. Thus, although specific embodiments have been illustrated and described herein, it should be appreciated that any arrangement calculated to achieve the same purpose may be substituted for the specific embodiments shown. This disclosure is intended to cover any and all adaptations or variations of various embodiments. Combinations of the above embodiments, and other embodiments not specifically described herein, will be apparent to those of skill in the art upon reviewing the above description.
In one embodiment, a mobile device for non-repudiable endorsement of a private attestation is provided. The device can include a power supply to provide power, a memory to store instructions and data, a communication module to transmit and receive data, a display to present information and receive user input; and a processor to run a computer program. The computer program comprises a non-transitory computer readable medium storing program code to be executed by at least one computer processing unit (CPU) in a computational environment, whereby execution of the program code causes the at least one CPU to perform operations comprising: receiving an Attestation from a Private Attribute Provider (PAP), wherein the Attestation that includes attributes and corresponding attribute values; binding a user of the mobile device to the Attestation; and binding pivotal attributes of said attributes to equivalent attributes of an Issuing Authority.
Binding a user includes collecting a set of user certified attribute names, but not attribute values, from said attributes selected by the user via said display, authenticating the user to the Issuing Authority, generating a key pair for the user, comprising a public key (PuK) and a private key (PrK) and storing in said memory, transmitting said public key (PuK) to said Issuing Authority via said communication module, requesting the Issuing Authority for its authorization to endorse said Attestation based on it, and validating said set of user certified attribute names. If validated, it includes receiving from said Issuing Authority a signed Server Proof; aggregating the signed Server Proof with a Verifier Challenge to produce a Verifier Blob; signing the Verifier Blob with said private key (PrK) to produce a mobile signed blob; packaging the Attestation with the mobile signed blob to produce an Endorsed Attestation; and presenting said Endorsed Attestation to a Verifier to access a service offered by said Verifier.
The processor 810 may include one or more data processing circuits, such as a general purpose and/or special purpose processor, such as a microprocessor and/or digital signal processor (e.g., GPU, P, ASIC, DSP, CPLD, IC, etc.). The processor 810 is configured to execute computer program code in the memory 820, described below as a non-transitory computer readable medium, to perform at least some of the operations described herein as being performed by an identified component, module or software block. The computer program code can include computer instructions, assembly code, firmware, or embedded code, machine code, that when executed by the processor 810 causes the processor 810 to perform operations in accordance with one or more embodiments disclosed herein.
Specific examples (a non-exhaustive list) of the computer readable storage medium exemplified by memory 820 can include the following: a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM), Flash memory (NAND, NOR), a solid state device (SSD), an appropriate optical fiber (FICON) with a repeater, an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.
The processor 810 may also be communicatively attached to a co-processor 811 (on-board or off board), one or more CPU cores 812 and one or more crypto processors 813 (e.g., HW crypto accelerator) that assist in off-loading computational or processing tasks.
The sensors 840 can detect or measure a physical property and record, indicate, or otherwise responds to the sensory information. The sensors 840 provide for measurement of temperature, humidity, radio frequency, electromagnetic, light, force, pressure, acceleration, movement, position, tilt, and other physical interaction and environmental conditions. The Sensors 840 may further include a signal comparator, a phase comparator, an analog to digital converter, amplifier, signal filter, etc. used to enable the processor 810 to receive and process signals from one or more sensors.
The security module 830 provides for monitoring of security violations, security risks, unauthorized uses and attacks on the platform 800. It may be a mixed signal low-power microcontroller that include decision logic, memory or software and that communicatively couples to the sensors 840 and the processor 810. The security module 830 may include software and logic, or share resources and responsibilities with the processor 810, to detect security events, such as tamper levels, thresholds, and conditions.
The platform 800 may include a wired network communication interface 850 and/or a wireless interface 860, for example, a radio access communication transceiver. The wired network interface can include standard computer networking interfaces used in local area networks (LAN), wide area networks (WAN), over the Cloud, and the Internet and other frame based or packed based networks. The Ethernet interface can use TCP/IP and UDP protocols for 10/100/1000 Mbps transmission over standard Cat 5, Cat 5e, or Cat 6 cables. The radio access communication transceiver can include, but is not limited to, a LTE or other cellular transceiver, WLAN transceiver (IEEE 802.11), WiMAX transceiver, Bluetooth transceiver, NFC transceiver, Radio Frequency Identification (RFID) or other radio communication transceiver configured to communicate directly or indirectly (e.g., via a radio access node) with a network node.
The platform 800 may include User Interface (UI) communication (COMM) modules 880, for example, electronic data exchange or generic communication, such as Universal Serial Bus (USB), RS-232 serial port, smart card reader, Graphical User Interfaces (GUI), Light Emitting Diodes (LED), or other user related I/O interfaces.
The power supply 870 provides power to the electronic components of platform 800 and can include regulators and converters to provide required voltage and current requirements. The battery 875 can also provide power, for example, in low-power modes or when otherwise required for security reasons, for example, to maintain the contents of protected memory.
Consumers are increasingly using their mobile devices for a variety of applications for e-signatures, for instance, including securely storing and using credit cards for authorizing credit card transactions. The idea of using a mobile phone as an identity management device has been previously proposed. In such an arrangement, a key attestation process can rely on a service provider (SP) to perform a series of steps that result in an X.509 certificate chain that shows the provenance of the device back to an authority. But, since individual phones are not fully trusted, the industry needs a common, trusted approach. The protocol herein described for endorsing a private attestation can be a strong differentiator for attribute usage on mobile device. It can apply to various businesses: Mobile Wallet, CNIe, MultiAppvX, Mobile ID, e-ID, Mobile Wallet, ISO IEC 23220 on building blocks for mobile ID in ISO SC17 WG4 committee. CNIe is carte nationale idetentite electronique which is the French digital ID based on a card physical.
Device attestation allows organizations to learn about the security status of devices trying to connect to network apps and workspaces. The goal of attestation is to provide trustworthy evidence or proof about something. Identify attestation allows the device to provide proof of its hardware identifiers, such as serial number or IMEI. The concept of device attestation may similarly be applied to a user, or holder, of the device. In the case of a cybersecurity ecosystem, for example, this would suggest that a Relying Party (RP) like a bank or a cloud provider could be confident about the data they are receiving from the device, for example, a user document related to identification of the user presenting the device.
In the above-description of various embodiments of the present disclosure, aspects of the present disclosure may be illustrated and described herein in any of a number of patentable classes or contexts including any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof. Accordingly, aspects of the present disclosure may be implemented in entirely hardware, entirely software (including firmware, resident software, micro-code, etc.) or combining software and hardware implementation that may all generally be referred to herein as a “circuit,” “module,” “component,” or “system.” Furthermore, aspects of the present disclosure may take the form of a computer program product comprising one or more computer readable media having computer readable program code embodied thereon.
Any combination of one or more computer readable media may be used. The computer readable media may be a computer readable signal medium or a computer readable storage medium. A computer readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. In the context of this document, a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device.
A computer readable signal medium may include a propagated data signal with computer readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated signal may take any of a variety of forms, including, but not limited to, electro-magnetic, optical, or any suitable combination thereof. A computer readable signal medium may be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device. Program code embodied on a computer readable signal medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing.
Computer program code for carrying out operations for aspects of the present disclosure may be written in any combination of one or more programming languages, including an object oriented programming language such as Java, Scala, Smalltalk, Scheme, Go, C++, C#, VB.NET, Python or the like, conventional procedural programming languages, such as the “C” programming language, Perl, PHP, dynamic programming languages such as Python, Ruby and Groovy, or other programming languages. The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer, entirely on the remote computer or server, or within the Cloud or other computer network. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider) or in a cloud computing environment or offered as a service such as a Software as a Service (Saas), Backend as a Service (BaaS) for connecting mobile apps to cloud based services, and Security as a Service (SECaas).
Aspects of the present disclosure are described herein with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the disclosure. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable instruction execution apparatus, create a mechanism for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.
These computer program instructions may also be stored in a computer readable medium that when executed can direct a computer, other programmable data processing apparatus, or other devices to function in a particular manner, such that the instructions when stored in the computer readable medium produce an article of manufacture including instructions which when executed, cause a computer to implement the function/act specified in the flowchart and/or block diagram block or blocks. The computer program instructions may also be loaded onto a computer, other programmable instruction execution apparatus, or other devices to cause a series of operational steps to be performed on the computer, other programmable apparatuses or other devices to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide processes for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.
It is to be understood that the terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention. Unless otherwise defined, all terms (including technical and scientific terms) used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this disclosure belongs. It will be further understood that terms, such as those defined in commonly used dictionaries, should be interpreted as having a meaning that is consistent with their meaning in the context of this specification and the relevant art and will not be interpreted in an idealized or overly formal sense unless expressly so defined herein.
The flowchart and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various aspects of the present disclosure. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems that perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.
The terminology used herein is for the purpose of describing particular aspects only and is not intended to be limiting of the disclosure. As used herein, the singular forms “a”, “an” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms “comprises” and/or “comprising,” when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof. As used herein, the term “and/or” includes any and all combinations of one or more of the associated listed items. Like reference numbers signify like elements throughout the description of the figures.
The corresponding structures, materials, acts, and equivalents of any means or step plus function elements in the claims below are intended to include any disclosed structure, material, or act for performing the function in combination with other claimed elements as specifically claimed. The description of the present disclosure has been presented for purposes of illustration and description, but is not intended to be exhaustive or limited to the disclosure in the form disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the disclosure. The aspects of the disclosure herein were chosen and described in order to best explain the principles of the disclosure and the practical application, and to enable others of ordinary skill in the art to understand the disclosure with various modifications as are suited to the particular use contemplated.
| Number | Date | Country | Kind |
|---|---|---|---|
| 21306698.8 | Dec 2021 | EP | regional |
| Filing Document | Filing Date | Country | Kind |
|---|---|---|---|
| PCT/EP2022/084289 | 12/2/2022 | WO |
