Non-repudiation of private certificates

Abstract

A method (200) is provided for unrepudiable recognition of a private certificate (111). The method includes receiving a certificate from a private attribute provider (110) in response to a request from a user to declare the certificate, securely binding a critical attribute in the certificate selected by the user after being authenticated by an issuing authority (120), and securely binding the user to the certificate via a connected device (100). The method generates an approved certificate (400) including a signed server proof (360), which is provided by the user to a service provider via the connected device to receive a service (151) that would otherwise require a third-party trusted attestation. Other embodiments are also disclosed.

Description

Technical Field

[0001] The present invention relates to the technical field of electronic authentication and certification. One or more embodiments of the present invention generally relate to the field of cryptographic authentication. More specifically, the embodiments relate to methods and systems for the verification of proofs.

[0002] The present invention relates to newly developed methods for verifying and certifying the authenticity of personal documents issued by an attribute provider to an independent service provider when there is no trust chain.

[0003] The present invention contemplates means for alleviating concerns about the reliability regarding the authenticity of privately certified documents. Advantageously, the present invention provides a technical mechanism for the approval of certificates to users who wish to enhance the reliability of private certificates.

Background Art

[0004] Authentication is a security process, such as a sign-on process, that verifies a user's ID in a system that grants an individual the right to access the system. Authentication is important because it assigns responsibility to the user for the entries the user creates, modifies, or views. Authorization is the attribution of the creation or creation of a particular unit of information to a particular individual or entity acting at a particular point in time.

[0005] Certification is the act of witnessing the signature of an official document and signing in order to confirm that it has been properly signed by the people bound by its contents. Certification is the legal recognition of the authenticity of a document and the confirmation that the appropriate process has been followed. Certification may also be the act of electronically signing the content to indicate the authorship and legal responsibility of a particular unit of information. An electronic signature is a general, technically neutral term that refers to various methods of signing and certifying an electronic record.

[0006] Problem: Digital certificates (e.g., diplomas, certificates of qualifications) from private attribute providers (e.g., academic institutions, companies, associations, etc.) are generally considered suspicious, even if delivered through formal or official means. These certificates have inconsistent levels of reliability and are not linked to master or trust lists. In many cases, private attribute providers are unknown issuing authorities from the perspective of the relying party. Such private certificates are unreliable because, if a user delivers them to the relying party on their own, the user may modify them or they may be forged copies. Therefore, when a relying party requests a user to present a digital certificate issued by a private attribute provider (e.g., an academic institution), the relying party wants to be sure that the digital certificate belongs to the user presenting it and that its authenticity has been verified by a reliable source.

[0007] Currently, organizations need to access separate resources to verify specific existing information regarding electronic signatures, certifications, and authorship of user documents. Such verification is a costly and time-consuming process. Privacy issues regarding the sharing of user information and personal data become particularly relevant in verifications related to user identification. There is no common system that holds all of an individual user's identity information. Nor is there a single overwhelmingly accepted standard, law, or regulation for device verification of a user's identity.

[0008] While specific specifications (GP, ISO, ETSI, CEN / CENELEC, W3C, GSMA) promote abstract concepts regarding the authentication and trust of digital user identification documents, they do not provide concrete implementations. In this regard, ISO / IEC 18013-5 proposes a standardized method for interacting with mobile IDs (mIDs) and mobile driver licenses (mDLs) for use cases of IDs and driving rights. An open mDL / mID ecosystem compliant with global interoperability standards would provide a level of trust comparable to traditional passports or user identification. The ISO / IEC 18013-5 international mDL standard draft aims to provide a mechanism for retrieving and trusting ID document data from mobile driver licenses, but the specification is complex and does not provide any details on implementation.

[0009] The problem with these proposed standards is that they do not provide for the implementation of digital certificate authorization from private attribute providers. Such identity verification is time-consuming and costly, and there is generally little benefit for relying parties to independently verify complex credentials. Furthermore, governments or public institutions are reluctant to agree to provide more data than insurance liabilities would allow when asked to verify digital credentials.

[0010] This invention overcomes existing limitations and provides a solution that advantageously facilitates closer involvement between private attribute providers and private service providers in cryptographic ecosystems where users are seeking to enhance the trustworthiness of private certificates, for example, through connected devices. [Overview of the project]

[0011] In the first embodiment, a method for the non-repudiation of a private certificate is provided. This method includes the step of receiving a certificate from a private attribute provider (PAP), the certificate including attributes having corresponding attribute names and values, and an optional PAP signature signed by the PAP. • Binding the user of a connected device to a certificate, and • Binding extremely important attributes to equivalent attributes of the issuing authority. It is further characterized by...

[0012] The two bindings described above provide a stronger level of reliability enhancement than the latest technologies. The step of binding a user of a connected device to a certificate includes collecting a set of user authentication attribute names from user-selected attributes, authenticating the user to the issuing authority, generating a user key pair including a public key (PuK) and a private key (PrK), and sending the public key (PuK) to the issuing authority. The step of binding critical attributes to the equivalent attributes of the issuing authority includes requesting the issuing authority to authenticate the user and approve the certificate based on that, and verifying the set of user authentication attribute names. If verified, the process includes receiving a signed Server Proof from the issuing authority, aggregating the signed Server Proof with a Verifier Challenge to generate a Verifier Blob, signing the Verifier Blob with a private key (PrK) to generate a Mobile Signed Blob, packaging the certificate with the Mobile Signed Blob to generate an Endorsed Attestation, and presenting the Endorsed Attestation to the verifier to access services provided by the verifier. In the step of binding critical attributes, the issuing authority checks the validity of the set of user authentication attribute names against their equivalent corresponding attribute values, and if valid, performs the steps of approving the certificate along with the set of user authentication attribute names, the hashed certificate and the hashed public key, and returning a signed Server Proof; otherwise, if invalid, it performs the step of not approving the certificate.

[0013] The approval step includes signing the server proof to generate a signed server proof that includes a hashed certificate, a hash of the user authentication attribute name, an issuing authority challenge, and a hashed public key. The approved certificate includes a mobile signed blob that includes the certificate and an optional PAP signature, as well as a connected device signature to the verifier blob using the private key (PrK), and the verifier blob. The verifier blob includes a verifier challenge and a signed server proof. The signed server proof includes a hashed certificate, a hash of the user authentication attribute name, an issuing authority challenge, a hashed public key, and an issuing authority signature. The validity check step includes authenticating the user authentication attribute name against any source of pre-registered information for connected device authentication of the user of the connected device, such as a citizen register, identity register, administrative register, or user ID register. Access to the service grants rights or privileges to the user of the device holding the device key.

[0014] The certificate may further include the purpose of using attributes that restrict access by the PAP, and the purpose within the certificate may include terms of use, expiration dates, or other conditional means for using the approved certificate. The terms of use, expiration dates, or other conditional means may be included in the issuing authority challenge to restrict the issuing authority's use of the approved certificate. Approving the certificate along with a set of user authentication attribute names and the hashed certificate and hashed public key binds the user to the key pair of the connected device, thereby preventing the user from rejecting the connected device signature.

[0015] In a second embodiment, a method is provided for non-repudiation pre-authorization of a private certificate via a connected device. This method includes the step of receiving a certificate from a private attribute provider (PAP), the certificate including 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 certificate, and 2) binding critical attributes to equivalent attributes of the issuing authority. The step of binding a user of the connected device to the certificate includes collecting a set of user authentication attribute names from user-selected attributes, authenticating the user to the issuing authority, generating a user key pair including a public key (PuK) and a private key (PrK), and sending the public key (PuK) to the issuing authority. The step of binding critical attributes to equivalent attributes of the issuing authority includes requesting permission from the issuing authority to authorize the certificate based thereon and verifying the set of user authentication attribute names.

[0016] If verified, the method further includes receiving a signed server proof from the issuing authority, aggregating the signed server proof with the PAP challenge to generate a pre-approved blob, signing the pre-approved blob with a private key to generate a mobile-signed pre-approved blob, and presenting the mobile-signed pre-approved blob to the PAP for authentication. If authentication is successful, the method includes receiving a PAP-signed certificate and reconstructing the approved certificate with the verifier challenge. The step of reconstructing the approved certificate includes aggregating the signed server proof with the verifier challenge to generate a verifier blob, signing the verifier blob with a private key (PrK) to generate a mobile-signed blob, packaging the PAP-signed certificate with the mobile-signed blob to generate an approved certificate, and presenting the approved certificate to the verifier to access the services provided by the verifier.

[0017] In a third embodiment, a system for the non-repudiation of private certificates is provided. This system comprises an issuing authority, a verifier, and a private attribute provider (PAP) for providing certificates containing attributes and corresponding attribute values. The connected device operated by the user further features binding the user to the certificate and binding critical attributes to the equivalent attributes of the issuing authority. In response to the binding, the connected device aggregates the signed server proof received from the issuing authority with the verifier challenge from the verifier to generate a verifier blob, signs the verifier blob to generate a mobile signed blob, packages the certificate with the mobile signed blob to generate an approved certificate, presents the approved certificate to the verifier, and accesses the services provided by the verifier. The connected device binds the user to the certificate by collecting a set of user authentication attribute names, rather than attribute values, from user-selected attributes, authenticating the user to the issuing authority, generating a user key pair containing a public key (PuK) and a private key (PrK), and sending the public key (PuK) to the issuing authority.

[0018] The connected device requests permission from the issuing authority to approve a certificate based on it, verifies a set of user authentication attribute names, and, if verified, binds critical attributes to the issuing authority's equivalent attributes by receiving a signed server proof from the issuing authority. The issuing authority checks the validity of the set of user authentication attribute names against their own corresponding attribute values, and if valid, approves the certificate along with the set of user authentication attribute names, the hashed certificate, and the hashed public key, and returns a signed server proof; otherwise, it does not approve the certificate if it is invalid. The issuing authority signs the server proof to generate a signed server proof that includes the hashed certificate, hashes of the user authentication attribute names, an issuing authority challenge, and a hashed public key.

[0019] In a fourth embodiment, a connected device is provided for the non-repudiation of a private certificate. The device comprises a power supply, memory for storing instructions and data, a communication module for sending and receiving data, a display for presenting information and receiving user input, and a processor for executing a computer program. The computer program comprises a non-temporary computer-readable medium for storing program code that is executed by at least one central processing unit (CPU) in a computing environment, so that the execution of the program code causes at least one CPU to perform the operation of the method described above. In one configuration, the method comprises receiving a certificate from a private attribute provider (PAP), the certificate comprising attributes and corresponding attribute values, and is further characterized by binding the user of the connected device to the certificate and binding the most important attributes of the attributes to equivalent attributes of the issuing authority.

[0020] The system described herein is designed to be compatible with the Electronic Identification and Trust Services for Electronic Transactions (elDAS2) rules. For example, by introducing a role called a “Gov Server” established by an elDAS-Qualified Trust Service Provider (TSP), the system may be applied to the elDAS2 context and comply with the rules. Through this practice, a user can request a TSP to provide a QEAA (Qualified Attribute Award) which will play a role in approving private certificates delivered by any private attribute provider. In this configuration, the TSP signs a composite (e.g., attribute, certificate, proof, etc.) called a “Signed Gov Proof.” In this way, private certificates may be approved by the TSP, except by verifying the EAA of the QEAA (Qualified Attribute Award / Electronic Certificate), providing a reliable way to bridge the gap between private and public certificates while protecting privacy. [Brief explanation of the drawing]

[0021] The features of the present invention are considered to be novel and are described in detail in the appended claims. The present invention, as well as its further objects and advantages, may be best understood by reference to the following description taken in conjunction with the accompanying drawings. In several of the figures, like reference numerals identify like elements.

[0022] [Figure 1] Example diagram for using to approve a private certificate according to an embodiment [Figure 2] Diagram showing a method for non-repudiable approval of a private certificate according to an embodiment [Figure 3] Schematic diagram of an approved certificate generated by the method of FIG. 2 according to an embodiment [Figure 4A] Diagram showing a binding path in the approved certificate of FIG. 3 according to an embodiment [Figure 4B] Diagram showing a binding point in the approved certificate of FIG. 3 according to an embodiment [Figure 5] Diagram showing a method for reusing a signed server proof in an approved certificate according to an embodiment [Figure 6] Diagram showing a method for non-repudiable pre-approval of a private certificate according to an embodiment [Figure 7] Exemplary schematic diagram of a machine suitable for use to execute the present method according to an embodiment [Figure 8] Diagram showing a hardware platform suitable for use to execute the present method according to an embodiment

Mode for Carrying Out the Invention

[0023] This specification concludes with claims that define the features of the present invention regarded as novel, but the present invention is considered to be better understood by considering the following description in conjunction with the drawings that carry forward like reference numerals.

[0024] In computing, attributes are specifications that define the properties of an object, element, or file. They can also refer to or set specific values ​​for a particular instance. Many object-oriented languages ​​allow certain attributes to be declared private, making it difficult, if not impossible, for a user of a class to directly view or modify their values. Class developers provide ways to control how these attributes can be manipulated or used. The protocol for approving private certificates described here may be used by users to approve certificates signed with their chosen attributes. Private attribute providers may also require this protocol before applying their signature to a certificate.

[0025] Attributes from private attribute providers need to be validated with two strong performance enhancements: 1) linkage to the owner, and 2) linkage to critically important attributes certified by the issuing authority. Identity verification is costly, and relying parties in such positions gain little benefit from independently checking complex credentials. Furthermore, contractual liability generally becomes an issue when third parties, such as government agencies, are included as trusted sources to support verification. Obtaining consent and distributing data in response to requests for digital credential validation is difficult. The embodiments herein provide solutions to overcome these limitations.

[0026] Referring to Figure 1, a high-level use case diagram for approving a private certificate according to the first embodiment is shown. In this use case, the user ultimately wants to obtain service 151 from service provider 130. The service provider can be considered a verifier (130) or a dependent party. In order to receive service 151, the service provider requires a private certificate 111 from private attribute provider (PAP) 110, and it must be guaranteed that certificate 111 is indeed trustworthy. To provide this guarantee, issuing authority 120 is included as a party that enhances the user's trust.

[0027] The issuing authority approves the private certificate by means of the method described herein and generates an approved private certificate. Through approval, the service provider is assured that the private certificate 111 is genuine and trustworthy. The user then presents the approved private certificate to the service provider 130 as a condition for receiving service 151. Access to service 151 grants the user of the mobile device holding the device key a right or privilege.

[0028] Example Figure 100 illustrates a common high-level method (steps 141-146) for non-repudiation of a private certificate as a solution for a user to enhance the trustworthiness of their private certificate before delivery to a service provider 130 (or a relying party). This involves introducing the issuing authority 120 to the user and the service provider as a trusted source and intermediary for the authorization. In this example, the service provider 130 requests a digital certificate issued by the private attribute provider from the user and receives assurance through the authorized certificate from the issuing authority that the received digital document belongs to the user and that the key (critically important) user ID attributes covered in the certificate have been verified and validated.

[0029] For example, suppose a user is a former student who graduated from an academic institution (e.g., PAP110) and is seeking privileges from an alumni association (e.g., service provider 130). The user has obtained a digital diploma from PAP110, which awarded the user their degree, containing relevant user identification information. The diploma includes the user's name, graduation date, awarding institution, and academic field. In this example, service provider 130 is an alumni association that can grant the user privileges (e.g., service 151), but the user must be present to receive the diploma from the institution in order to receive the service or privileges, i.e., the conditions for the service. Service provider 130 may also be a third-party verifier working on behalf of the alumni association to authorize the user. The user may have a copy of their diploma or a photograph of their diploma (physical or on a mobile device) to present as evidence to the alumni association, but this would impose time, cost, and effort on the alumni association (or a third-party affiliate) to verify the authenticity of the diploma (copy or photograph). It is preferable to receive the diploma directly from the degree-granting institution. This is because it is a more reliable source than a single user. However, even in this case, both the PAP (e.g., an academic institution) and the service provider (e.g., an alumni association) are burdened with the task of communicating and establishing a foundation of trust.

[0030] In this example, in step 141, the user requests a digital document that identifies the user, and in step 142, the PAP 110 responds with a private certificate 111, which is proof that the provided digital document is indeed true and authentic. This proves the personal information contained in the digital document. The user can then present the private certificate. Another configuration of use case 100 discussed earlier provides a solution in which the Private Attribute Provider (PAP) requires prior approval to mitigate the risk of "misdelivery" of the certificate.

[0031] However, as mentioned above, it is necessary to endorse a certificate from a trusted source other than the user. Endorsement is similar to a digital certificate that proves the authenticity of something. To provide this assurance, the user authenticates with the issuing authority 120 in step 143, and during authentication, the issuing authority 120 selects critical attributes (e.g., first name, last name, date of birth, place of birth) within the private certificate 111 for independent verification. In step 144, the issuing authority verifies the critical attributes and responds with a server proof, meaning the private certificate corresponds to the user. In step 145, the server proof is combined with the private certificate to generate an endorsed private certificate 400. In step 146, the user presents the endorsed private certificate to the service provider 130 and receives the service 151.

[0032] Referring to Figure 2, a method 200 for the non-repudiation of a private certificate by a mobile device is shown. This method may involve more or fewer steps than shown, and is not limited to the order of the steps shown. When considering this method, refer to other figures to show the available components. This method is shown in the context of a computing ecosystem where a user with a connected device 100 requests a service provided by a verifier 130. The connected device may be a mobile phone, laptop, or other electronic communication device.

[0033] Method 200 can begin with step 201, in which the user requests a (private) certificate from PAP 110 to the connected device 100. The user collects the certificate from the PAP. In this example, the certificate claims a recognized graduation for John Smith, born October 23, 1980, in Utopia. The PAP controls how private attributes can be proven. For example, an academic institution is a PAP that can prove that a particular degree was awarded to a particular student on a particular date. A company that provides user identification badges (IDs) is another example of a PAP that can prove that a particular badge was given to a particular employee for a particular period of time to enter a particular area or to access a particular computer system. An organization that provides access to services to registered users is another example of a PAP that can provide a certification service.

[0034] In step 202, the PAP responds with a certificate, and the connected device 100 stores the certificate. The certificate contains attributes with corresponding attribute values. In the exemplary use case of Figure 1, an exemplary list of attribute names and attribute values ​​is shown below.

[0035] [Table 1]

[0036] In step 206, the mobile device presents the user with a list of attribute names in the certificate and prompts the user to select a subset of attribute names rather than attribute values ​​to protect privacy. This is a set of user authentication attribute names and is similarly considered “critically important” attributes. Briefly referring to Figure 3, the critically important attributes 302 selected by the user are identified and marked (e.g., A, B, C) within the certificate 300 which contains all attributes. In particular, attribute values ​​may be included in the certificate 300 along with their corresponding attribute names, but the way the approved certificate 400 is generated relies solely on the (user authentication) attribute names selected by the user and does not require attribute values. In this step, the user can approve the certificate by binding its configuration attributes (attribute name-value pairs) to their equivalent attributes (attribute name-value pairs) in variable sources (e.g., user input, elDCard, cloud service, Gov service). The user is prompted to select attribute names (not attribute values) as the critically important attributes (e.g., first name, last name, date of birth, place of birth) that they wish to use to approve the certificate.

[0037] In step 208, the user authenticates with the issuing authority 120 via the connected device 100. The user authenticates with the issuing authority 120 from their mobile device, for example, a government server (e.g., login / password or additional authentication vector or elDCard, or OOB pre-acquired secret). In this step, the user generates a key pair <user public key (PuK) and user private key (PrK)> on their mobile device and sends an authorization request to the government server to authorize the certificate, along with a set of critical attribute names {e.g., first_name, last_name, birthdate, place_of_birth}, a hash of the certificate (the certificate is not revealed in plain text for privacy reasons), and a hash of the user public key (HPuK). The step of authorizing the certificate with the set of user authentication attribute names and the hashed certificate and hashed public key binds the user to the generated key pair on the mobile device, thereby preventing the user from rejecting the certificate authorization (and mobile device signing).

[0038] In step 210, the issuing authority 120 1) retrieves user attributes, 2) hashes the user attributes, 3) signs the token as a server proof, and 4) records {hash (PAP.certificate) + UID + hash of used attributes}. Specifically, the issuing authority 120 independently verifies critical attribute names against attribute values ​​already possessed from user authorization or attribute values ​​found through searching its own trusted sources. Verifying critical attributes against equivalent attributes of the issuing authority is a verification process. This is one element of the server proof. Once the issuing server 120 has obtained its own independent attribute values ​​for selected critical attribute names, it examines the certificate to confirm that the corresponding attribute name-value pairs are consistent, i.e., that the attribute values ​​of the names in the certificate are correct from its own research / search perspective. For example, a government server checks the validity of attributes in a certificate to ensure that the attribute name / value pairs of an authenticated user match attribute name / value pairs in, for example, a civil register, identity register, or administrative register.

[0039] In step 212, the issuing authority 120 returns a signed server proof if the matching exercise of the results of the investigation is successful. For example, if a government server checks successfully, it will return a signed Gov server proof. This proof consists of an attribute hash, a challenge (or unique identifier UID), and a hashed certificate. In step 214, the mobile device saves the signed server proof for later use. At this point, the user has the server proof necessary to satisfy the verifier's user identification request. Communication with the issuing authority 120 can be terminated. The user then proceeds to communicate with the verifier 130.

[0040] In step 216, the user requests access to a service provided by the verifier (or source provider or relying party). In the following example, the service may be alumni privileges for students who attended a particular academic institution. The user logs into the verifier service on their mobile device and requests the service. The verifier 130 responds in step 218 with a verifier challenge provided to the user's mobile device. At this point, the user instructs the mobile device to generate an approved certificate, as shown in step 220. The connected device 100, under the user's instructions, aggregates the Gov server proof using the verifier challenge from the verifier / SP / RP, signs the entire package (using the user's device key - user private key PrK), and consequently generates an approved certificate. A detailed description of the exemplary approved certificate 400 is shown and provided in Figure 3.

[0041] Once the mobile device generates an approved certificate 400, the user sends it to the verifier 130 in step 222. In other words, the user delivers the approved certificate to the verifier / SP / RP in order to access services or be granted rights such as access to the alumni webpage. The verifier 130 checks the payload of the approved certificate 400 (see Figure 3) to determine whether the certificate provided by the user matches the server proof. This allows the verifier to extract the necessary attribute names / values ​​from the certificate and determine and provide services to the user. The verifier then performs the usual PKI actions necessary to verify key usage and certificate verification.

[0042] Referring to Figure 3, a schematic diagram of the approved certificate 400 is shown. The approved certificate 400 consists of certificate 300 and mobile signed blob 320. The specific selection of attribute 303 is considered a critical attribute 302 (e.g., A, B, C, also called user authentication attribute names). These are "critical" in the sense that the user selects a specific attribute name (not a value) from within the certificate, and the issuing authority independently verifies it. The approved certificate 400 consists of certificate 300 with an optional PAP signature 304 and mobile signed blob 320. Note that the PAP signature is optional and not a required element of an approved certificate. Rather, certificate approval refers to the presentation (combination) of certificate 300 and mobile signed blob 320, regardless of whether a PAP signature is present or not.

[0043] Certificate 300 includes the intended use of each attribute, such as terms of use, expiration date, or other conditional means for using the approved certificate 400. The intended use may be provided by PAP 110 or the user. Certificate 300 includes a signature 304 confirming that it was signed by PAP. However, attaching the PAP signature 304 to Certificate 400 is optional if it is considered a prerequisite for the issuing authority to approve Certificate 300.

[0044] The mobile signed blob 320 comprises a verifier blob 340 and a mobile signature 322 (represented as a key). The mobile signature 322 is created by the connected device 100 (see Figures 2 and 3B) when it signs the verifier blob 340 using the user private key (PrK) stored on the device. The verifier blob 340 comprises a signed server proof 360 and a verifier challenge 342. The signed server proof 360 comprises the server proof provided by the issuing authority 120, along with the issuing authority signature 362 (represented as a key) to verify that it was signed by the issuing authority 120. The server proof 360 comprises a hash of the certificate 300 (hashed certificate 370), a hash of the user authentication attribute name (hashed user authentication attribute 371), an issuing authority challenge 372, and a hash of the user public key (PuK) (hashed user public key 373). The user private key (PrK) and user public key (PuK) are corresponding key pairs created and stored on the connected device 100 by the user. The key pairs are generated according to the guidelines and recommendations of the Public Key Infrastructure (PKI). Thus, the signed server proof 360 comprises the server proof (elements 370-373) and the issuing authority signature 362.

[0045] Simply put, Figures 4A and 4B show the binding paths and binding points of the various entities involved in the approval of the certificate, provided by Method 200 for creating the approved certificate 400 (see Figure 3) in Figure 2, respectively. Binding points are the result of creating corresponding non-repudiation binding paths that prevent the user or involved entities (issuing authority or verifier) ​​from refuting the validity of the assembled / packaged components of the approved certificate 400 (Figure 3). Binding points and paths also establish how components can be reused. For example, once approved, a user can reuse signed server proofs when requesting services from various verifiers. However, a user can only reuse server proofs signed with the same certificate.

[0046] Referring here to Figure 4A, the binding paths of the various entities involved in approving the certificate are shown. Binding path 401 occurs between PAP110 and certificate 300 when PAP110 creates and signs the certificate, thereby generating the PAP signature 362 (Figure 3A). Binding path 402 occurs when PAP101 signs the certificate, with one or more purposes involving the use of critical attributes 302. Binding path 403 occurs when issuing authority 120, containing the hashed certificate 370, signs the server proof with its issuing authority signature 362. Binding path 404 occurs when issuing authority 120, containing the hashed user authentication attribute names 371, signs the server proof with its issuing authority signature 362. This binds the critical attributes selected by the user (user authentication attribute names 302, e.g., A, B, and C) to equivalent attributes verified by the issuing authority. Binding path 405 occurs when issuing authority 120 signs the server proof with its issuing authority signature 362 when generating the signed server proof 360. Binding path 406 occurs because issuing authority 120 includes an issuing authority challenge 372 within the signed server proof 360.

[0047] Bindings 407-408 create a non-repudiation path by binding the user of connected device 100 to certificate 300, preventing the user from denying that they selected the critical attributes used by the issuing authority to approve the certificate requested by the user, or from denying that they did not create a verifier blob 340 to request service from verifier 130. Binding path 407 occurs when the user's mobile device signs verifier blob 340 with the user's private key (PrK) to generate a mobile signed blob 320. Binding path 408 occurs when the user provides the issuing authority with the user's public key (PuK) and requests authentication and approval for certificate 300. Binding 388 is non-repudiation because the hashed user public key (PuK) 373 is embedded in the signed server proof 360. Binding path 409 binds the user to verifier 130 when the mobile device constructs an approved certificate 400 specific to the challenge provided by the verifier (or source provider, or relying party).

[0048] Referring here to Figure 4B, the binding points of the various entities involved in the creation of the approved certificate 400 are shown. Components previously shown in Figure 4B will also be referenced numerically. Binding point 420 establishes that only critical attributes (user authentication attribute name 302, Figure 3) can be approved by the issuing authority. Binding point 421 connects the certificate 300 to the mobile device and establishes the user's commitment. At this point, the issuing authority approves the certificate at the user's request, and this constitutes the user's commitment because the certificate contains the critical attributes 302 selected by the user. Binding point 422 proves that the user cannot deny willingly approving the certificate. Binding point 423 proves that the user cannot deny their selection of the critical attributes related to the approval.

[0049] Binding point 424 obligates the user to replay the server proof only for the same certificate. Point 425 binds the user to authorization from the issuing server. This binding may include properties or terms of use established by the issuing authority, such as the expiration date of the server proof or other conditions, as well as the purpose field of the certificate. Binding point 426 binds the user to a user private key (PrK) created and stored by the user on a mobile device. Therefore, the user cannot refuse to sign because the signed server proof contains a copy of the corresponding user public key (PuK).

[0050] Binding point 427 establishes the uniqueness of the selected verifier and binds the approved certificate to that specific verifier. Including the verifier challenge 342 in the verifier blob 340 is under the control of the user and connected device 100, allowing the user to create other approved certificates unique to other verifiers. In other words, embedding the verifier challenge 342 in the verifier blob 340 and signing the package with the user's private key (PrK) on the mobile device generates a mobile signed blob 320 unique to the verifier. This configurable ability to include the verifier challenge 342 in the mobile signed blob enables a "approve once, reuse many times" approach. Users can reuse signed server proofs, but some things can only be done by using the same certificate.

[0051] Referring to Figure 5, a method 500 is shown for reusing a server proof signed by a different verifier for an application to subscribe to a different service or privilege. In this method, the user has already received a signed server proof, for example, following steps 201-214 of the method in Figure 2. As seen in that figure, in step 214, the signed server proof is saved for later use, for example, as in this example where the user wishes to receive a service from a different verifier.

[0052] In Method 500, in step 502, the user requests a service from the verifier 130. In step 504, the verifier 130 returns a verifier challenge. In step 506, the user generates an approved certificate 400 via the connected device 100, similar to the steps and description shown in Figure 2. However, here the mobile device embeds a new (different) verifier challenge into the verifier blob 340 and signs this blob with the user's private key (PrK) 102 stored in the connected device 100. The procedure of Method 500 is similar to the procedure of Method 200, but includes a different verifier challenge.

[0053] In step 508, the user presents the approved certificate to verifier 130. In step 510, the verifier checks the package for its contents and accuracy (checking user signature and attributes), and if OK, grants access to the service. In step 512, i.e., after confirming that the provided certificate matches the server proof, the verifier determines which service to provide. This allows the user to reuse the same server proof from the government server with multiple different verifiers (service providers or dependent parties). In particular, only the verifier / RP challenge binds the user to the verifier / RP. Therefore, the government server proof can be reused with multiple verifiers / RPs, as long as permitted by the terms of use.

[0054] Referring to Figure 6, a method 600 for non-repudiation pre-approval of a private certificate via a mobile device is provided. Method 600 may include more or fewer steps than shown, and is not limited to the order of the steps shown. When considering this method, other figures will be referred to to show the available components. This method is presented in the context of a computing ecosystem where a user with a connected device 100 requests a certificate provided by PAP 110. Here, the user supplements method steps 201-204 of Figure 2 to receive a digital certificate in connection with the communication of information provided to PAP 110. This use case arises when PAP is not confident in the legitimacy of the user's certificate request and wants assurance in the form of pre-approval by the issuing authority before releasing the certificate to the user. In other words, the user must first find a signed server proof and send it back to PAP 110 as a condition for receiving the certificate. This is necessary because PAP 110 does not have a simple means of authenticating the user (requester) and wants to avoid handing the certificate over to a fraudster. Therefore, PAP110 requires reliance on an issuing authority as a condition for issuing certificates.

[0055] In step 602, the user sends a request for a certificate (e.g., a diploma) to PAP110. The user receives a certificate from the Private Attribute Provider (PAP) that includes the attribute, the corresponding attribute value, and the PAP Challenge 604. However, in step 606, PAP110 requests pre-approval before adding a signature 388 to the certificate. In particular, the unsigned certificate 299 returned by PAP110 in step 606 does not contain a signature. Rather, it contains the PAP Challenge 604 as a signaling for pre-approval. Therefore, the user cannot continue to use certificate 299 as done in method 200 because the PAP signature is not present in step 606. Note that at this point, it is an "unsigned" certificate.

[0056] Similar to how it was done in Method 200, Method 600 here involves binding the user of the mobile device to the certificate. Therefore, similarly, the user must first select a set of user authentication attribute names (critically important attributes) from the attributes identified in the unsigned certificate 299, rather than attribute values. The user authenticates with the issuing authority 120 (see Figure 2), generates a user key pair containing a public key (PuK) and a private key (PrK), and sends the public key (PuK) to the issuing authority. The issuing authority then binds the critically important attributes to its equivalent attributes. The user requests permission from the issuing authority via the mobile device to approve the unsigned certificate 299 (still without a PAP signature) based on it, verifies the set of user authentication attribute names (critically important attributes), and, if verified, receives a signed server proof from the issuing authority. This is part of step 608 (Performing Pre-Approval) and includes the mobile device aggregating the signed server proof with the PAP challenge to generate a pre-approved blob, signing the pre-approved blob with the private key (PrK) 102 to generate a mobile-signed pre-approved blob, and presenting the mobile-signed pre-approved blob to the PAP for authentication in step 610. Note that the hash (certificate) here refers to an "unsigned" certificate.

[0057] In step 612, the PAP authenticates the pre-approved data package by checking the signed and hashed attributes of the mobile-signed pre-approved blob (similar to the approved certificate 400, but including the PAP challenge 604 instead of the verifier challenge 342). If authenticated, in step 614, the PAP sends the PAP-signed certificate, including the PAP signature 388, to be received by the connected device 100. Note that the certificate is now "signed". In this case, the certificate 300 is in the same format as the certificate in method 200 in Figure 2, and the PAP optionally signs the certificate to now include the PAP signature 388. In step 616, the mobile device reconstructs the approved certificate using the selected verifier challenge, as described / illustrated by method 500 in Figure 5; i.e., reuse of the server proof. Reconstructing an approved certificate involves aggregating the signed server proof with the verifier challenge to generate a verifier blob 620, signing the verifier blob with a private key (PrK) to generate a mobile signed blob 630, packaging the PAP signed certificate with the mobile signed blob to generate an approved certificate, and presenting the approved certificate to the verifier in order to access the services provided by the verifier.

[0058] The advantages derived from the embodiments described herein include, but are not limited to, the following: About the user: • Easy-to-use certificates and simplified steps towards RP (no identity verification process). • Privacy-compliant approvals that enhance the value of private certificates with reference attributes (see Figures 1 and 2) • Possibility of using reference attributes from various sources (ElDCard, cloud, direct input, etc.) • The possibility of reusing the same Gov server proof across multiple verifiers / RPs (see Figure 5). About the verifier / SP / RP: • Eliminates the need for costly identity verification (saves on the cost of identity verification against the Relying Point). • Enhanced non-repudiation and reliability levels of certificates (see Figure 4A / B) About private attribute providers: • There is no risk of impersonation or the transfer of certificates to unauthorized persons. • Optional pre-approval to reduce the risk of "misdelivery" without actual additional costs. • By requiring prior approval before signing the certificate, one can benefit from this invention (see Figure 6). About the issuing authority (government server): The government does not have access to private certificate content (GDPR compliant) and is therefore not in a position to verify it. • The government will not disclose any attribute values ​​(after user authentication, the government will only provide a signed hash of the selected attributes and a method to bind it to the user and document hashes). • Proof from the government may optionally include terms of use and a validity period (see Figure 4B).

[0059] system In one embodiment, a system for the non-repudiation of private certificates is provided. This system comprises an issuing authority, a verifier, a private attribute provider (PAP), and a mobile device. The PAP provides a certificate containing attributes and corresponding attribute values. The user-operated mobile device binds the user to the certificate and binds critical attributes to equivalent attributes of the issuing authority. In response to this binding, the mobile device aggregates the signed server proof received from the issuing authority and the verifier challenge from the verifier to generate a verifier blob, signs the verifier blob to generate a mobile signed blob, packages the certificate with the mobile signed blob to generate an approved certificate, and presents the approved certificate to the verifier to access services provided by the verifier.

[0060] The mobile device binds the user to the certificate by collecting a set of user authentication attribute names, rather than attribute values, from user-selected attributes. The mobile device authenticates the user to the issuing authority, generates the user's key pair including a public key (PuK) and a private key (PrK), and sends the public key (PuK) to the issuing authority. The mobile device requests permission from the issuing authority to approve the certificate based on it, binding critical attributes to the issuing authority's equivalent attributes by verifying the set of user authentication attribute names. If verified, the mobile device receives a signed server proof from the issuing authority.

[0061] The issuing authority checks the validity of the user authentication attribute name set against its corresponding attribute values, and if valid, approves the certificate along with the user authentication attribute name set, the hashed certificate, and the hashed public key. The issuing authority returns a signed server proof, or does not approve the certificate if it is invalid. The issuing authority signs the server proof to generate a signed server proof. The signed server proof includes the hashed certificate, the hash of the user authentication attribute names, the issuing authority challenge, and the hashed public key.

[0062] Figure 7 shows an exemplary schematic diagram of a machine 700 in the form of a computer system 700, which, when a series of instructions within it are executed, may cause the machine to perform one or more of the methods considered above (e.g., by PAP 110, issuing authority 120, or service provider 130). In some embodiments, the machine operates as a standalone device such as a computer, laptop, mobile device, remote control, or display. In some embodiments, the machine may be connected to other machines (e.g., using a network). In a networked deployment, the machine may operate as a server or client user machine in a server-client-user network environment, or as a peer machine in a peer-to-peer (or distributed) network environment.

[0063] A machine may include a server computer, a client user computer, a personal computer (PC), a tablet PC, a laptop computer, a desktop computer, a mobile device, a mobile phone, a control system, a network router, a switch or bridge, or any machine capable of executing a set of instructions (sequentially or otherwise) that specify the actions that the machine will take. It will be understood that the devices of this disclosure broadly include any electronic device that provides voice, video, or data communications. Furthermore, although a single machine is illustrated, the term “machine” should be understood to also include a collection of machines that individually or collectively execute a set of instructions (or sets of instructions) for performing one or more of the techniques considered herein.

[0064] The computer system 700 may include a processor 702 (e.g., a central processing unit (CPU), a graphics processing unit (GPU, or both), main memory 704, and static memory 706, which communicate with each other via a bus 708. The computer system 700 may further include a video display device 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 also include an input device 712 (e.g., a keyboard, a touchless sensing unit 110), a cursor control device 714 (e.g., a mouse, a 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.

[0065] The disk drive unit 716 includes a machine-readable medium 722 which stores one or more instruction sets (e.g., software 724) that embody one or more of the techniques or functions described herein, including the methods described above. The instructions 724 may reside entirely or at least partially in the main memory 704, static memory 706, and / or processor 702 while being executed by the computer system 700. The main memory 704 and processor 702 may also constitute machine-readable medium.

[0066] To implement the methods described herein, dedicated hardware implementations can also be constructed, including but not limited to application-specific integrated circuits, programmable logic arrays, and other hardware devices. Applications, which may include devices and systems of various embodiments, broadly include various electronic and computer systems. In some embodiments, relevant control and data signals are communicated between modules, through modules, or implemented in two or more specific interconnected hardware modules or devices as part of an application-specific integrated circuit. Thus, this exemplary system is applicable to software, firmware, and hardware implementations.

[0067] According to various embodiments of this disclosure, the methods described herein are intended to operate as software programs running on a computer processor. Furthermore, software implementations include, but are not limited to, distributed processing or component / object distributed processing, and parallel processing. Alternatively, virtual machine processing can also be constructed to perform the methods described herein.

[0068] Although the machine-readable medium 722 is shown as a single medium in exemplary embodiments, the term “machine-readable medium” should be interpreted to include a single or multiple mediums (e.g., a centralized or distributed database, and / or associated caches and servers) that store one or more instruction sets. The term “machine-readable medium” should also be interpreted to include any medium that can store, encode, or carry instruction sets executed by a machine, causing the machine to execute one or more of the methods of the present disclosure.

[0069] Accordingly, the term “machine-readable media” shall be deemed to include, but not be limited to, solid-state memory such as memory cards or other packages containing one or more read-only (non-volatile) memories, random-access memories, or other rewritable (volatile) memories; magneto-optical or optical media such as disks or tapes; and carrier signals such as signals that embody computer instructions on a transmission medium; and / or digital file attachments to email or other self-contained information archives or archive sets shall be deemed to be equivalent distribution media to tangible storage media. Accordingly, the disclosure shall be deemed to include one or more machine-readable media or distribution media, including technically recognized equivalents and successor media listed herein, on which software implementations herein are stored.

[0070] The drawings of the embodiments described herein are intended to provide a general understanding of the structure of various embodiments and are not intended to serve as a complete description of all elements and features of the devices and systems that may utilize the structure described herein. Many other embodiments will become apparent to those skilled in the art from the above description. Structural and logical substitutions and modifications may be made by utilizing and deriving from other embodiments without departing from the scope of this disclosure. The drawings are also representative only and may not be drawn to scale. Certain proportions may be exaggerated, while others may be minimized. Therefore, this specification and the drawings should be considered illustrative rather than restrictive.

[0071] Such embodiments of the subject matter of the invention may, for convenience, be referred to herein individually and / or collectively in the term “invention,” but this is not intended to arbitrarily limit the scope of this application to any single invention or inventive concept when multiple inventions or inventive concepts are actually disclosed. Therefore, while certain embodiments are illustrated and described herein, it should be understood that any configuration calculated to achieve the same objective may be used instead of the specific embodiment shown. This disclosure is intended to cover all adaptations or variations of various embodiments. Combinations of the above embodiments, and other embodiments not specifically described herein, will be apparent to those skilled in the art upon consideration of the above description.

[0072] Mobile devices (110) In one embodiment, a mobile device for the non-repudiation of a private certificate is provided. The device may comprise a power supply, memory for storing instructions and data, a communication module for sending and receiving data, a display for presenting information and receiving user input, and a processor for running a computer program. The computer program includes a non-temporary computer-readable medium for storing program code that is executed by at least one central processing unit (CPU) in a computing environment, and the execution of the program code causes at least one CPU to perform operations including receiving a certificate containing attributes and corresponding attribute values ​​from a private attribute provider (PAP), binding the user of the mobile device to the certificate, and binding the most important attributes of the attributes to equivalent attributes of the issuing authority.

[0073] Binding a user includes collecting a set of user authentication attribute names, rather than attribute values, from attributes selected by the user via the display; authenticating the user to the issuing authority; generating and storing in memory a user key pair containing a public key (PuK) and a private key (PrK); sending the public key (PuK) to the issuing authority via a communication module; requesting permission from the issuing authority to approve a certificate based on it; and verifying the set of user authentication attribute names. If verified, it includes receiving a signed server proof from the issuing authority; aggregating the signed server proof and the verifier challenge to generate a verifier blob; signing the verifier blob with the private key (PrK) to generate a mobile signing blob; packaging the certificate with the mobile signing blob to generate an approved certificate; and presenting the approved certificate to the verifier to access services provided by the verifier.

[0074] Figure 8 shows a hardware platform 800 suitable for use as a computing environment for performing the method steps described above for the connected device 100, or for use within it. The platform 800 comprises a processor 810, memory 820, and security 830, a sensor 240, a communication module indicated as a wired interface 850 and / or a wireless interface, a power supply 870, a battery 875, and a user interface (UI) 880. These components may be communicatively coupled by direct hardware interfaces between them, including but not limited to electronics, circuits, wiring, lines, logic, or gates, as shown in the figure or where appropriate.

[0075] The processor 810 may include one or more data processing circuits, such as general-purpose processors and / or dedicated processors, for example, microprocessors and / or digital signal processors (e.g., GPUs, □Ps, ASICs, DSPs, CPLDs, ICs, etc.). The processor 810 is configured to execute computer program code in the memory 820 described below as a non-temporary computer-readable medium and to perform at least some of the operations described herein when executed by certain components, modules, or software blocks. The computer program code may include computer instructions, assembly code, firmware, or embedded code, machine code, etc., which, when executed by the processor 810, cause the processor 810 to perform operations according to one or more embodiments disclosed herein.

[0076] Specific examples (non-exclusive list) of computer-readable storage media illustrated by memory 820 may include hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), flash memory (NAND, NOR), solid-state devices (SSDs), suitable optical fibers with repeaters (FICON), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0077] The processor 810 may also be communicatively mounted to a coprocessor 811 (onboard or offboard) that assists in offloading computational or processing tasks, one or more CPU cores 812, and one or more cryptographic processors 813 (e.g., hardware cryptographic accelerators).

[0078] Sensor 840 can detect or measure physical properties, record, display, or respond to their perceived information. Sensor 840 measures temperature, humidity, radio frequency, electromagnetic, light, force, pressure, acceleration, motion, position, tilt, and other physical interactions and environmental conditions. Sensor 840 may further include signal comparators, phase comparators, analog-to-digital converters, amplifiers, signal filters, etc., which enable processor 810 to receive and process signals from one or more sensors.

[0079] The security module 830 monitors for security breaches, security risks, misuse, and attacks against the platform 800. The security module 830 may be a mixed-signal low-power microcontroller comprising decision logic, memory, or software, and communicatively coupled with the sensor 840 and 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 tampering levels, thresholds, and conditions.

[0080] Platform 800 may include a wired network communication interface 850 and / or a wireless interface 860, such as a wireless access communication transceiver. The wired network interface may include standard computer networking interfaces used in local area networks (LANs), wide area networks (WANs), cloud networks, the Internet, and other frame-based or packet-based networks. The Ethernet interface may use TCP / IP and UDP protocols for 10 / 100 / 1000 Mbps transmission over standard Cat5, Cat5e, or Cat6 cables. The wireless access communication transceiver may include, but is not limited to, an LTE or other cellular transceiver, a WLAN transceiver (IEEE 802.11), a WiMAX transceiver, a Bluetooth transceiver, an NFC transceiver, a radio automatic identification (RFID), or other wireless communication transceivers configured to communicate directly or indirectly with network nodes (e.g., via a wireless access node).

[0081] Platform 800 may include a user interface (UI) communication (COMM) module 880, such as an electronic data interchange or general-purpose communication module, including a Universal Serial Bus (USB), RS-232 serial port, smart card reader, graphical user interface (GUI), light-emitting diode (LED), or other user-related I / O interface.

[0082] Power supply 870 may include regulators and converters that power the electronic components of platform 800 and provide the necessary voltage and current requirements. Battery 875 can also supply power when needed, for example, in low-power mode or for security reasons, such as maintaining the contents of protected memory.

[0083] Further definitions and embodiments: Consumers are increasingly using mobile devices for a variety of electronic signature applications, such as securely storing and using credit cards to authorize credit card transactions. The idea of ​​using mobile phones as identity management devices has been proposed before. In such configurations, the key authentication process may rely on a service provider (SP) that performs a series of steps resulting in an X.509 certificate chain that traces the device's origin back to a certification authority. However, since individual phones are not entirely trustworthy, the industry needs a common, reliable approach. The protocol for authorizing private certificates described here could be a strong differentiator for the use of attributes on mobile devices. This is applicable to a variety of businesses, including mobile wallets, CNIe, MultiAppvX, mobile ID, e-ID, mobile wallets, and ISO IEC 23220 on the building blocks of mobile ID by the ISO SC17 WG4 committee. CNIe is a French digital ID based on a physical card, known as carte nationale idententite electronicique.

[0084] Device authentication allows organizations to know the security status of devices attempting to connect to network applications or workspaces. The purpose of authentication is to provide reliable evidence or proof of something. Identity authentication allows devices to prove hardware identifiers such as serial numbers or IMEIs. The concept of device authentication can also apply to the user or owner of a device. For example, in a cybersecurity ecosystem, this would mean that a relying party (RP), such as a bank or cloud provider, can be confident about the data they receive from a device, such as user documentation related to the identification of the user presenting the device.

[0085] In the above descriptions of various embodiments of the Disclosure, aspects of the Disclosure may be illustrated and described herein in any of a number of patentable classes or contexts, including any novel and useful processes, machines, manufactures, or compositions, or any novel and useful improvements thereof. Accordingly, aspects of the Disclosure may be implemented entirely in hardware, entirely in software (including firmware, resident software, microcode, etc.), or as a combination of software and hardware, all of which may be generally referred to herein as “circuits,” “modules,” “components,” or “systems.” Furthermore, aspects of the Disclosure may take the form of a computer program product comprising one or more computer-readable media having computer-readable program code embodied thereon.

[0086] Any combination of one or more computer-readable media may be used. Computer-readable media may be computer-readable signal media or computer-readable storage media. Computer-readable storage media may, but are not limited to, electronic, magnetic, optical, electromagnetic, or semiconductor systems, apparatus, or devices, or any suitable combination thereof. In the context of this document, computer-readable storage media may be any tangible medium on which programs used by or in connection with instruction execution systems, apparatus, or devices can be stored or preserved.

[0087] A computer-readable signaling medium may contain propagating data signals, for example, in the baseband or as part of a carrier wave, in which computer-readable program code is embodied. Such propagating signals may take any of a variety of forms, including but not limited to electromagnetic, optical, or any suitable combination thereof. A computer-readable signaling medium may not be a computer-readable storage medium, but any computer-readable medium on which a program can be communicated, propagated, or transported by or in connection with an instruction execution system, apparatus, or device. Program code embodied on a computer-readable signaling medium may be transmitted using any suitable medium, including but not limited to wireless, wired, fiber optic cable, RF, or any suitable combination thereof.

[0088] Computer program code for performing the actions described in this disclosure may be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Java, Scala, Smalltalk, Scheme, Go, C++, C#, VB.NET, and Python; traditional procedural programming languages ​​such as the C programming language, Perl, and PHP; dynamic programming languages ​​such as Python, Ruby, and Groovy; or other programming languages. The program code may run entirely on a user's computer, partially on a user's computer, as a standalone software package, partially on a user's computer and partially on a remote computer, entirely on a remote computer or server, or in 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 wide area network (WAN), or the connection may be to an external computer (for example, via the Internet using an Internet Service Provider), or in a cloud computing environment, or provided as a service such as Software as a Service (SaaS), Backend as a Service (BaaS) for connecting mobile apps to cloud-based services, and Security as a Service (SECaaS).

[0089] Aspects of the present disclosure are described herein with reference to flowcharts and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the present disclosure. It will be understood that each block in a flowchart and / or block diagram, and combinations of blocks in a flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general-purpose computer, a dedicated computer, or other programmable data processing device to generate a machine such that instructions executed via the processor of the computer or other programmable instruction execution device create a mechanism for implementing the functions / operations specified by the blocks or combinations of blocks in the flowchart and / or block diagram.

[0090] These computer program instructions may also be stored on computer-readable media and, when executed, can instruct a computer, other programmable data processing device, or other device to function in a particular way. Therefore, when stored on computer-readable media, instructions, when executed, generate a product containing instructions that cause a computer to implement a function / action specified within a block or multiple blocks of a flowchart and / or block diagram. Computer program instructions can also be loaded onto a computer, other programmable instruction execution device, or other device to perform a series of operational steps on the computer, other programmable device, or other device, thereby generating a computer implementation process. Therefore, instructions executed on a computer or other programmable device provide a process for implementing a function / action specified within a block or multiple blocks of a flowchart and / or block diagram.

[0091] It should be understood that the terms used herein are for the purpose of describing only specific embodiments and are not intended to limit the invention. Unless otherwise defined, all terms used herein (including technical and scientific terms) have the same meaning as generally understood by those skilled 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 the same meaning as those defined herein and in the related art, and should not be interpreted in an ideal or overly formal sense unless expressly defined herein.

[0092] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of the systems, methods, and computer program products of the present disclosure in various aspects. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions described in a block may occur in the order shown in the figure. For example, two blocks shown consecutively may actually be executed substantially simultaneously, or blocks may be executed in reverse order depending on the functions involved. It should also be noted that each block in a block diagram and / or flowchart, and combinations of blocks in a block diagram and / or flowchart, may be implemented by a dedicated hardware-based system or a combination of dedicated hardware and computer instructions that performs a particular function or operation.

[0093] The terms used herein are for the purpose of describing only specific aspects and are not intended to limit the disclosure. Where used herein, the singular forms “a,” “an,” and “the” are intended to include the plural form unless the context otherwise explicitly indicates. Where used herein, the terms “contains” and / or “contains” specify the presence of the described features, integers, steps, actions, elements, and / or components, but do not exclude the presence or addition of one or more other features, integers, steps, actions, elements, components, and / or groups thereof. Where used herein, the terms “and / or” include any and all combinations of one or more of the related enumerated items. Throughout the description of the drawings, similar reference numbers indicate similar elements.

[0094] Any means or steps and corresponding structures, materials, actions, and equivalents of functional elements in the following claims are intended to include any disclosed structures, materials, or actions for performing a function in combination with other claimed elements, particularly those claimed. The descriptions in this disclosure are presented for illustrative and explanatory purposes and are not intended to be exhaustive or to be limited to the disclosed forms. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of this disclosure. The aspects of the disclosure herein have been selected and described to best illustrate the principles and practical uses of this disclosure and enable those skilled in the art to understand this disclosure with various modifications suitable for specific intended uses.

Claims

1. A method (200, 600) for non-repudiation and pre-approval of a private certificate via a user's mobile device (100), wherein the method comprises: Receiving (202) a signed or unsigned certificate (300) from a private attribute provider (PAP) in response to a certificate request from a mobile device (100), wherein the certificate (300) includes an attribute (303) having a corresponding attribute name and attribute value. A PAP signature (304) is considered a prerequisite for the issuing authority (120) to authorize and release a certificate (300) to the user, or PAP Challenge (604) as a signaling of pre-approval for the issuing authority (120) before the certificate is released to the user. It consists of one of the following, This involves prompting the user to select a subset of attribute names, rather than attribute values, from the certificate (300) that are called extremely important attributes (302) that the user wants the issuing authority (120) to approve, and The process involves authenticating the user to the issuing authority (120) via a mobile device (100) for authorization and requesting a signed server proof (360), To generate a user key pair comprising a public key (PuK) and a private key (PrK) (102) stored on a mobile device (100), Sending the public key (PuK) to the issuing authority (120), The process involves requesting the issuing authority (120) to approve the certificate (300) after verifying a subset of attribute names, thereby allowing the issuing authority (120) to obtain its own independent attribute values ​​for the most important attributes (302), examine the certificate (300) to confirm that the corresponding attribute name-value pairs match the register from the perspective of its own investigation and retrieval, In response to verification, receive a signed server proof (360) from the issuing authority (120) comprising a hashed certificate (370) of the certificate (300), a hashed user authentication attribute (371) of a subset of attribute names, an issuing authority challenge (372), and a hashed user public key (373) of the public key (PuK). To generate an approved certificate (400) from a signed server proof (360) depending on whether a PAP signature (304) or PAP challenge (604) is included in the certificate (300), The user presents the approved certificate (400) to the verifier (130) to access the service (151) provided by the verifier (130). Methods that include...

2. When the mobile device determines that the certificate includes a PAP signature, The signed server proof (360) is aggregated with the verifier challenge (342) to generate a verifier blob (340), The process involves signing the verifier blob (340) with the private key (PrK) (102) to generate a mobile-signed blob (320), The certificate (111) is packaged with the mobile-signed blob (320) to generate the approved certificate (400), When a mobile device determines that the certificate contains a PAP challenge, The signed server proof is aggregated with the PAP challenge to generate a pre-approved blob, This involves signing a pre-approved blob with a private key to generate a mobile-signed pre-approved blob, and If you present the mobile-signed pre-approved blob to PAP (110) for authentication and it is authenticated (612), Receiving a PAP-signed (388) certificate (300) and Reconstructing (616) an approved certificate (400) and a PAP-signed (388) certificate (300) that has a verifier challenge (342) The method of claim 1, further comprising:

3. With regard to binding extremely important attributes, the issuing authority (120) (210) step of checking the validity of a set of attribute names for equivalent corresponding attribute values, If valid, the certificate is approved along with a set of attribute names, a hashed certificate, and a hashed public key. The step of returning a signed server proof (212), rather If the certificate is invalid, perform the step of not approving it. The method of claim 1, wherein approval includes signing a server proof and generating a signed server proof.

4. Approval certificate (400) Certificate (300) and PAP signature (304), Including mobile-signed blobs (320), Mobile-signed blobs (320) Mobile device signing on a verifier blob using a private key (PrK), Verifier Blob (340) Verifier Blob (340) Verifier Challenge (372), Includes a signed server proof (360), The signed server proof (360) hashed certificate (370), The hash of attribute names (373), Issuer Challenge (342), hashed public key (373), The method of claim 2, comprising issuing authority signature (322).

5. The method of claim 4, wherein the step of approving the certificate together with a subset of attribute names and a hashed certificate and a hashed public key binds the user to a mobile device key pair (407) and thereby prevents the user from rejecting the mobile device signature.

6. The method of claim 2, wherein the issuing authority (120) examines the certificate (300) by authenticating attribute names against any source of pre-registered information for the authentication of a mobile device user of a mobile device (100), and confirms that the corresponding attribute name-value pairs match against the register.

7. The method of claim 1, wherein access to the service (151) grants rights or privileges to the user of the device holding the private key, and the certificate further includes the purpose of using attributes that restrict access by PAP, and the purpose in the certificate includes terms of use, expiration date, or other conditional means for using an approved certificate (400).

8. The method of claim 1, further comprising conditional means, such as terms of use and expiration date, for using the approved certificate (400) in an issuing authority challenge (342) to restrict the use of the approved certificate (400) by the issuing authority (120).

9. A method (600, 200) for non-repudiation and pre-approval of a private certificate via a user's mobile device (100), wherein the method comprises: Receiving a signed or unsigned certificate (300) from a private attribute provider (PAP) (110) in response to a certificate request from a mobile device (100), wherein the certificate includes an attribute (303), a corresponding attribute name and value, A PAP signature (304) is considered a prerequisite for the issuing authority (120) to authorize and release a certificate (300) to the user, or PAP Challenge (604) as signaling for pre-approval by the issuing authority (120) before the certificate is released to the user. It consists of one of the following, The process involves authenticating the user to the issuing authority via a mobile device (100) for authorization and requesting a signed server proof (360), To generate a user key pair comprising a public key (PuK) and a private key (PrK) stored on a mobile device (100), Sending the public key (PuK) to the issuing authority and The process involves requesting the issuing authority (120) to approve the certificate (300) after verifying a subset of attribute names, thereby allowing the issuing authority (120) to obtain its own independent attribute values ​​for the most important attributes (302), examine the certificate (300) to confirm that the corresponding attribute name-value pairs match the register from the perspective of its own investigation and retrieval, In response to verification, the system receives a signed server proof (360) from the issuing authority (120), comprising a hashed certificate (370) of the certificate (300), a hashed user authentication attribute (371) of a subset of attribute names, an issuing authority challenge (372), and a hashed user public key (373) of the public key (PuK). To generate an approved certificate (400) from a signed server proof (360) depending on whether a PAP signature (304) or PAP challenge (604) is included in the certificate (300), The user presents the approved certificate (400) to the verifier (130) to access the service (151) provided by the verifier (130). Methods that include...

10. When the mobile device (100) determines that the certificate includes a PAP challenge, The signed server proof is aggregated with the PAP challenge to generate a pre-approved blob, The process involves signing a pre-approved blob with a private key to generate a mobile-signed pre-approved blob (630), and If the mobile-signed pre-approved blob (630) is presented to the PAP (110) for authentication, and authenticated (612), Receiving a PAP-signed (388) certificate (300) and The step of reconstructing the approved certificate is to reconstruct (616) the approved certificate (400) and the PAP signed (388) certificate (300) which have a verifier challenge (342), The signed server proof is aggregated with the verifier challenge to generate a verifier blob (620), The process involves signing the verifier blob with a private key (PrK) to generate a mobile-signed blob (320), and The PAP-signed certificate (300) is packaged with the mobile-signed blob (320) to generate an approved certificate (400), When a mobile device determines that the certificate contains a PAP signature, The signed server proof (360) is aggregated with the verifier challenge (342) to generate a verifier blob (340), The process involves signing the verifier blob (340) with the private key (PrK) (102) to generate a mobile-signed blob (320), The certificate (111) is packaged with the mobile signed blob (320) to generate the approved certificate (400). The method of claim 9, including the method of claim 9.

11. A system for non-repudiation and pre-approval of private certificates, The issuing office (120), Verifier (130), A private attribute provider (PAP) (110), A certificate (400) is provided that is signed or unsigned by a private attribute provider (PAP) and has attributes (303) and corresponding attribute values. If a PAP signature (304) is considered a prerequisite for the issuing authority to approve and release a certificate (400) to a user, or Certificate (400) is released to users before the PAP Challenge (604) serves as a signaling of prior approval for the issuing authority. A private attribute provider (PAP) (110) consisting of any of the following: A mobile device (100) operated by a user, Collecting a subset of attribute names, rather than attribute values, from the attributes (303) selected by the user, Authenticating the user to the issuing authority (120), To generate a user key pair comprising a public key (PuK) and a private key (PrK) (102), By sending the public key (PuK) to the issuing authority (120) Bind the user to the certificate, Requesting the issuing authority to authorize the user and approve the certificate, Validating a subset of attribute names, Receiving a signed server proof (360) from the issuing office, and To generate an approved certificate (400) from a signed server proof (360) depending on whether a PAP signature (304) or PAP challenge (604) is included in the certificate (300), By presenting an approved certificate to the verifier (130), the user can access the services provided by the verifier (130), A mobile device (100) that binds extremely important attributes to equivalent attributes of the issuing station and A system that includes these features.

12. Collect a subset of attribute names, rather than attribute values, from the attributes selected by the user, Authenticate the user to the issuing authority, Generate a user key pair consisting of a public key (PuK) and a private key (PrK). Send the public key (PuK) to the issuing authority. The system of claim 11, wherein a mobile device binds a user to a certificate.

13. After verifying a subset of attribute names, request permission from the issuing authority to approve the certificate, If verified, Receive a server proof signed by the issuing authority. The system of claim 12, wherein the connected device binds a critically important attribute to an equivalent attribute of the issuing station.

14. The issuing office, Check the validity of a subset of attribute names for their corresponding attribute values, If valid, the certificate is approved along with a subset of attribute names, the hashed certificate, and the hashed public key. It returns a signed server proof, and not, If the certificate is invalid, it will not be approved. The system of claim 13, wherein the issuing authority signs a server proof to generate a signed server proof comprising a hashed certificate, a hash of an attribute name, an issuing authority challenge, and a hashed public key.

15. A mobile device (100) for non-repudiation and pre-approval of private certificates, A power source (870) that supplies electricity, A memory (820) for storing instructions and data, A communication module (850) that sends and receives data, A display (880) that presents information and receives user input, It comprises a processor (810) that executes computer programs, A computer program includes a non-temporary computer-readable medium that stores program code to be executed by at least one central processing unit (CPU) on a mobile device, and the execution of the program code is performed by at least one central processing unit (CPU), Receiving a signed or unsigned certificate (300) from a private attribute provider (PAP) in response to a certificate request from a mobile device, wherein the certificate (300) includes attributes (303) and corresponding attribute values, A PAP signature (304) is considered a prerequisite for the issuing authority (120) to authorize and release a certificate (300) to the user, or PAP Challenge (604) as a signaling of pre-approval for the issuing authority (120) before the certificate is released to the user. It consists of any of the following: Authenticating the user to the issuing authority via a mobile device (100) for authorization and requesting a signed server proof (360), To generate a user key pair comprising a public key (PuK) and a private key (PrK), and to store it in the memory of a mobile device (100), Sending a public key (PuK) to the issuing authority via a communication module, and The process involves requesting the issuing authority to approve the certificate after verifying a subset of attribute names, thereby allowing the issuing authority (120) to obtain its own independent attribute values ​​for the most important attributes (302), examine the certificate (300) to confirm that the corresponding attribute name-value pairs match the register from the perspective of its own investigation and retrieval. In response to verification, receive a signed server proof from the issuing authority, comprising a hashed certificate (370) of the certificate (300), a hashed user authentication attribute (371) of a subset of attribute names, an issuing authority challenge (372), and a hashed user public key (373) of the public key (PuK). When a mobile device determines that the certificate contains a PAP signature, The process involves aggregating signed server proofs with verifier challenges to generate verifier blobs. The process involves signing the verifier blob (304) with a private key (PrK) to generate a mobile-signed blob (320). The certificate is packaged with a mobile signed blob (320) to generate an approved certificate, or When a mobile device determines that the certificate contains a PAP challenge, The process involves aggregating signed server proofs with PAP challenges to generate pre-approved blobs. To generate a mobile-signed pre-approved blob (630) by signing it with a private key, If the mobile-signed pre-approved blob (630) is presented to the PAP (110) for authentication, and authenticated (612), Receiving a PAP-signed (388) certificate (300) (614), Reconstructing (616) an approved certificate (400) and a PAP-signed (388) certificate (300) that has a verifier challenge (342), and Presenting an approved certificate to the verifier (130) and accessing services provided by the verifier. A mobile device that performs actions including those mentioned above.

Images