WO2012013833A1 - Ststemas y metodos para usar claves criptografiicas - Google Patents

Ststemas y metodos para usar claves criptografiicas Download PDF

Info

Publication number
WO2012013833A1
WO2012013833A1 PCT/ES2010/070527 ES2010070527W WO2012013833A1 WO 2012013833 A1 WO2012013833 A1 WO 2012013833A1 ES 2010070527 W ES2010070527 W ES 2010070527W WO 2012013833 A1 WO2012013833 A1 WO 2012013833A1
Authority
WO
WIPO (PCT)
Prior art keywords
digital certificate
new
cryptographic
certificate
public key
Prior art date
Application number
PCT/ES2010/070527
Other languages
English (en)
French (fr)
Inventor
Jorge LÓPEZ HERNÁNDEZ-ARDIETA
Fernando HERNÁNDEZ ÁLVAREZ
Carlos JIMÉNEZ SUÁREZ
Original Assignee
Secuware
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Secuware filed Critical Secuware
Priority to PCT/ES2010/070527 priority Critical patent/WO2012013833A1/es
Publication of WO2012013833A1 publication Critical patent/WO2012013833A1/es

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/321—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/006—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols involving public key infrastructure [PKI] trust models
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements

Definitions

  • the invention generally relates to systems and methods for using and reusing cryptographic keys for different purposes.
  • the systems and methods described allow a user to reuse a pair of cryptographic keys for purposes that are different from the purposes under which the keys were initially issued, or to associate different / additional information, for example, fields of a certificate with the digital identity of the owner of the key pair.
  • Certain cryptographic systems use two keys, referred to as a public key and a private key.
  • the public key is publicly known and the private key is known only to a particular user.
  • a message or other data is encrypted using the public key and subsequently decrypted by the recipient using his private key.
  • the public and private keys are related in a way that allows the public key to encrypt a message so that only the related private key can decrypt the message.
  • anyone who knows the public key of a particular user can send an encrypted message to that user with a substantial certainty that only the intended recipient will be able to access the content of the message. This type of encryption is popular when messages and other data are communicated through public networks, such as the Internet.
  • the cryptographic operation can be reversed, in the sense that the private key can be used first to encrypt a cryptographic summary value or "hash" of the message, subsequently using the public key to decrypt it.
  • Certain digital signature schemes use this mode of operation. Thus, the authentication of the origin of the data and the integrity of the data are assured, since the origin is the only one that knows the private key and any modification of the signed message is detected.
  • the public key infrastructure was designed to allow the use of a public key cryptography (PKC) in open and insecure environments, and with an unlimited number of potential users.
  • PKI public key cryptography
  • the public key is linked to an identity through a digital certificate.
  • the issuer of the digital certificate is called the Certification Authority (CA).
  • CA Certification Authority
  • CA there are several levels of CA.
  • the CA on the first level is named as the root CA.
  • a CA issues the digital certificates of lower level entities, including possible subordinate CAs.
  • End user digital certificates are issued by CAs that belong to the last level of the hierarchy.
  • Each digital certificate is digitally signed by the corresponding issuer to ensure the authenticity of the information contained in the digital certificate.
  • a digital certificate is valid if its integrity is maintained (for example, the CA signature is verified correctly).
  • the validity of a digital certificate may also depend on a period of validity included in the digital certificate.
  • the status of a digital certificate is valid if the digital certificate has not been revoked or suspended by the subscriber or subscriber or other authorized entity. For example, the digital certificate should be revoked if the corresponding private key is compromised or the subscriber suspects that it has been compromised.
  • a digital certificate should also be revoked or suspended if the purposes for which the digital certificate was issued do not apply. For example, if a digital certificate was issued for an employee to access a company network, the digital certificate must be revoked when the employee contractually decouples from the company.
  • a digital certificate When a digital certificate is revoked, its serial number (unique in the specific PKI) is stored by the CA along with the revocation time and reason for. This information is typically stored in a certificate revocation list (CRL).
  • CCL certificate revocation list
  • a digital certificate When a digital certificate is revoked, the corresponding private key is no longer useful, thereby preventing inappropriate or malicious use of it.
  • the relationship between the subscriber and the CA is formalized through the use of a certification practice statement (CPS).
  • the CPS establishes the mechanisms and procedures followed by the CA to issue and manage digital certificates as well as the obligations, responsibilities and rights of the subscriber requesting a digital certificate.
  • the CPS also describes the registration process in which the user is authenticated by a registration authority (RA) before issuing the digital certificate. During this authentication process, the user provides information necessary to create the digital certificate. This information is authenticated by the RA using one or more techniques.
  • Fig. 1 represents an example of the entities involved in a public key infrastructure (PKI), how the systems and methods described here can be applied.
  • PKI public key infrastructure
  • Fig. 2 represents an example of a system capable of implementing the procedures described here.
  • Fig. 3 represents a flow chart of an example procedure for issuing a digital certificate.
  • Fig. 4 represents a flow chart of an example procedure for issuing a new digital certificate.
  • Fig. 5 represents an example exchange between an end user and a certification authority (CA) to issue a new digital certificate.
  • CA certification authority
  • the systems and methods described here reuse cryptographic keys embedded in a cryptographic hardware device (HCD), such as a smart card or a USB security credential.
  • HCD cryptographic hardware device
  • These systems and methods expand the utility of the private key while maintaining existing security requirements.
  • certain operations may require issuing a new public key to allow additional uses of the key or to add new fields that allow the use of the public-private key pair in new applications.
  • the user can operate the HCD in a normal way, but the public key held in the HCD is extracted and a new digital certificate with the new uses of the key (or new fields) is requested from the appropriate certification authority ( AC).
  • AC certification authority
  • the user does not need to replace his existing HCD, using his existing public-private key pair with the new purposes.
  • the re-issuance of cryptographic keys is transparent to the user. In particular, the user does not need to request a new key pair with new uses or fields, which would require the user to manage multiple HCDs. Instead, the existing key pair is expanded with new uses or fields while the
  • Fig. 1 represents an environment 100 where different entities of a public key infrastructure (PKI) interact to apply the systems and methods described here.
  • Environment 100 supports the issuance of digital certificate as well as the validation of digital certificate.
  • a certification authority (CA) 102 is accessed from the subscriber system 104, a system 106 belonging to the verifier of the possible digital signature or encrypted data received in a transaction initiated with the subscriber system 104, a registration authority (RA ) 108, and a validation authority (VA) 112.
  • the subscriber system 104 is a computer or other device capable of performing the subscriber-based tasks described herein.
  • the subscriber system 104 includes an HCD 110 that stores the public-private key pair associated with the subscriber.
  • the HCD 110 is any type of hardware device capable of storing public-private key pairs as described here. Exemplary HCDs include smart cards, USB credentials (Universal Serial Bus), and the like. The HCD 110 may also store other data used by the subscriber.
  • the system 106 belonging to the verifier is a computer or other device capable of performing the tasks based on the verification of digital signatures or decryption of data described herein.
  • a subscriber requests a digital certificate by presenting credentials to the registration authority 108 to prove the identity of the subscriber. This identification process can be carried out remotely using online or in-person methods, such as the physical identification of the person through a national identity document of the subscriber.
  • the registration authority 108 communicates validated subscriber information to the certification authority 102.
  • the activities of the registration authority 108 and the certification authority 102 may be performed by the same entity. In other cases, these activities can be carried out by two or more different entities.
  • Proper generation of the public-private key pair is important to ensure a high level of security within the environment 100.
  • the key pairs can be generated using a software application installed in the subscriber's system 104.
  • the certification authority 102 can generate key pairs using software and / or hardware components, which typically provide a higher level of security in the key pair generation process.
  • the subscriber registration process at the registration authority 108 is also important for security within the environment 100.
  • the certification authority 102 After the subscriber has been identified and authenticated appropriately, the certification authority 102 generates a digital certificate for said subscriber.
  • the digital certificate includes information provided by the registration authority 108, the public key and other parameters that depend on the certificate profile and the certification practice statement (CPS).
  • the certification authority 102 then provides the digital certificate to the subscriber. If the key pair is generated by the certification authority 102, then the subscriber also obtains the private key of the certification authority 102 via the Internet or physically at the location of the certification authority.
  • the digital certificate and the private key are stored in a software application. If the private key is issued for non-repudiation purposes, the certification authority 102 does not store a copy of the private key after distribution to the subscriber.
  • a digital certificate is a collection of information referring to the identity of the subscriber, the public key associated with that identity, and the identity of the issuer.
  • the digital certificate also includes a serial number that uniquely identifies the digital certificate within the public key infrastructure.
  • the digital certificates also include information regarding the validity period of the digital certificate and the purposes / applications for which the subscriber can use the private key associated with the public key that is contained in the digital certificate.
  • a particular digital certificate is issued for a specific subset of purposes, but not generally for all purposes. Exemplary purposes include digital signatures, data encryption, password confirmation, and certificate signing (commonly referred to as "cryptographic operations").
  • the verifier uses the certificate revocation list (CRL) to ensure that the digital certificate has not been revoked.
  • CRL certificate revocation list
  • the verifier system 106 may itself validate the received message or may request the validation of the message received by a validation authority (VA) 112.
  • VA validation authority
  • the validation authority 112 also uses the CRL obtained from the certification authority 102 to validate the digital certificates requested by the verifier.
  • the validation process performed by the trusting party or a validation authority validates the digital certificate (for example, to ensure that it has not been revoked).
  • the digital certificate is not valid if, for example, it has been revoked.
  • the trusted party or a validation authority can also validate cryptographic data (for example, digital signature, encrypted message, etc.) using the signer's digital certificate.
  • the verifier or the validation authority also validate the purpose for which the certificate is being used.
  • the certificate is not valid if it is being used for an unauthorized purpose.
  • FIG. 2 represents an exemplary system capable of implementing the procedures described here.
  • a subscriber computer 202 is able to communicate with the certification authority 102 and the registration authority 108.
  • the subscriber computer 202 can be any type of computing device capable of performing the operations described herein.
  • the subscriber computer 202 may be a desktop computer, a laptop, a handheld computer, a smartphone, a game console, a decoder, and the like.
  • the subscriber's computer 202 is coupled to a cryptographic hardware device (HCD) 216 via a universal serial bus (USB) or other communication link.
  • HCD cryptographic hardware device
  • USB universal serial bus
  • the particular embodiments of the HCD 216 include a smart card or a USB credential.
  • the HCD 216 can be any type of device capable of storing data and interacting with the subscriber's computer 202 as described herein.
  • Particular embodiments of HCD 216 include an EEPROM (Memory Only for Programmable Reading that can be Erase Electrically) to store data.
  • HCD 216 typically has limited storage space and may not allow storage of new data within the HCD after the initial public-private key pair and related data are stored within the HCD.
  • Other embodiments of HCD 216 allow the storage of new digital certificates and corresponding keys if space is available within the HCD.
  • the HCD 216 is inserted into a card reader or other device coupled to the subscriber's computer 202.
  • the subscriber's computer 202 includes a processor 204, a storage device 206, and a communication module 208.
  • the processor 204 performs various necessary operations during operation of the subscriber's computer
  • processor 204 performs various procedures and methods described herein to create, manage, and process different cryptographic data and related information.
  • the storage device 206 stores data and other information used during operation of the subscriber's computer 202.
  • the storage device 206 may include one or more volatile or non-volatile memories.
  • the storage device 206 includes a hard disk drive as well as volatile and non-volatile memories.
  • the communication module 208 communicates data between the subscriber's computer 202 and other devices, such as the certification authority 102 and the registration authority 108.
  • the subscriber's computer 202 also includes an application 210, a cryptographic module 212, and a cryptographic hardware unit 214. These three computer components (210, 212, and 214) of the subscriber 202 can be referred to as different "layers" of the system. .
  • Application 210 is a software application that makes use of the cryptographic systems and methods described herein when communicating data or performing other tasks that use cryptographic keys. Examples of application 210 include web-based applications, email platforms, applications for signature creation, and the like.
  • the cryptographic module 212 operates on a lower layer (for example, below the application 210) and communicates with the HCD 216 through the cryptographic hardware unit 214. In some embodiments, the cryptographic module 212 handles the data communication towards and from the certification authority 102.
  • the cryptographic hardware unit 214 communicates directly with the HCD 216, for example to retrieve the public key and other accessible information stored in the HCD 216.
  • HCD 216 stores a private key in a secure manner and allows access to the digital certificate that "wraps" the corresponding public key. Access to the digital certificate and its recovery can be optionally protected using a PIN or password. Access to the private key is protected by using a PIN or password.
  • the use of the public key is defined by different extensions of digital certificate, some of which have been described here. In some embodiments, the use of the public key includes all standardized key uses (for example, all purposes).
  • HCD 216 During normal use of HCD 216, the user may need to perform a cryptographic operation that is not supported by current uses / fields associated with the public key stored in the HCD. For example, an email application may require a digital certificate that includes an email field. If the existing digital certificate stored in HCD 216 does not include an email field, a new digital certificate is required to allow that the email application performs its designated function.
  • Fig. 3 represents a flow chart of an exemplary procedure 300 for issuing a digital certificate.
  • a cryptographic module for example, cryptographic module 212 in Fig. 2 attempts to read the digital certificate from a cryptographic hardware device (for example HCD 216) in block 302. If access to the digital certificate is protected by a PIN / password, then the cryptographic module requests the PIN or password from the system user, such as the subscriber (block 304). This operation is optional - certain systems may not require a PIN or password to access the digital certificate.
  • the cryptographic module extracts the public key from the digital certificate and generates a certificate request message using CRMF (Certificate Request Message Format) and identifying the desired new use (block 306).
  • the certificate request message is signed by the system user (block 308) with the user having to enter the appropriate PIN or password.
  • the certificate request message is then sent to a certification authority (for example, certification authority 102) for the issuance of a new digital certificate (block 310).
  • the certification authority is selected based on the specific application context, such as an email application that wants a digital certificate that includes an email field, as described above.
  • the selected certification authority should be able to process CRMF requests and issue digital certificates with the use of the new key requested in the certificate request message.
  • a "Proof-of-Possession" has been included in the certificate request message using transparent messages for the user.
  • the "Proof of Possession” used may vary depending on the policies of the certification authority and / or the registration authority.
  • the cryptographic module After treatment by the certification authority, the cryptographic module receives the new digital certificate (block 312).
  • the cryptographic operation is then performed by the subscriber's computer using the new digital certificate and the cryptographic hardware device (block 314).
  • the user is required to enter the PIN or password in order to perform the cryptographic operation.
  • the new digital certificate is not necessarily stored in the cryptographic hardware device.
  • the new digital certificate is used once and discarded. If a similar digital certificate is needed in the future, procedure 300 is repeated to obtain a new digital certificate.
  • the new digital certificate is stored within the cryptographic hardware device or stored in the subscriber's computer 202 (for example, in the storage device 206) for future use.
  • Fig. 4 represents a flow chart of an exemplary procedure 400 for issuing a new digital certificate.
  • the new digital certificate is issued for use during one or more sessions.
  • the new digital certificate is deleted at the end of each session - if another digital certificate is necessary in a future session, a different digital certificate is issued for use during that future session.
  • the procedure 400 generates a request for a new digital certificate identifying a new use and / or additional or different fields (block 402).
  • the new digital certificate is received from the certification authority (block 404) and the cryptographic operation is performed using the new digital certificate (block 406).
  • the procedure determines if the HCD has space to store the new digital certificate (block 408). If there is space available in the HCD, the procedure stores the new digital certificate in the HCD (block 410).
  • the procedure determines whether the current session has ended (block 412). In one embodiment, a session remains active while the cryptographic hardware device is connected to the subscriber's computer. If the session has not ended (that is, the session is still active), the new digital certificate remains available for subsequent cryptographic operations (block 414). When the session is over, the new digital certificate is deleted (block 416). If another session is activated in the future requiring a similar digital certificate for additional use, the procedure in fig. 4 is repeated. Procedure 400 allows a subscriber to add new uses / fields by keeping the key pair stored in an existing cryptographic hardware device instead of replacing it with a new device that stores a new key pair that supports the new uses / fields.
  • the procedure of fig. 4 is modified to generate a single-use digital certificate.
  • a single-use digital certificate is issued for use during a particular session, but deleted at the end of that session. If another digital certificate is needed in a future session, a different single-use digital certificate is issued for use during the future session.
  • the single-use digital certificate is stored, for example, in the RAM (Random Access Memory) or in a similar volatile storage device on the subscriber's computer.
  • a session remains active while the Cryptographic hardware device is connected to the subscriber's computer.
  • a session ends when the cryptographic hardware device is disconnected, causing the deletion of the single-use digital certificate from the subscriber's computer's RAM or other storage device.
  • This alternative procedure is similar to the procedure of fig. 4, except blocks 408 and 410.
  • the new digital certificate is used during the current session, and is not stored in the HCD, regardless of whether the HCD has space available to store the new digital certificate.
  • the new digital certificate is deleted at the end of a session even if the HCD is able to store the new digital certificate.
  • An exemplary implementation of the systems and methods described herein provides means for the protection of email messages.
  • email messages are protected using cryptographic techniques applied through software and / or hardware.
  • email messages can be protected without requiring any additional tools or new cryptographic hardware device that contains a new digital certificate that supports email message protection.
  • a modified digital certificate that includes the use of the specific key is requested and processed as described here.
  • the user sends secure email messages in which the user's identity is secured by cryptographic data, such as a digital signature.
  • the user only receives email messages in which the identity of the sender of the email is authenticated by means of the digital certificate (for example, the email field of the digital certificate includes the email address of the sender) .
  • This implementation significantly eliminates or reduces the amount of SPAM (bulk unsolicited email) received by the user.
  • the communication between the subscriber's computer 202 and the certification authority 102 uses the following procedure. Initially, the subscriber's computer 202 extracts the public key contained in the digital certificate embedded in the HCD 216. Once the public key is extracted from the HCD, the subscriber's computer generates a new certificate request message (in CRMF). This message requests a use of a new password (Use of Password) and / or new information fields (for example, an EMAIL field). The new certificate request message is protected with several methods that verify the Proof-of-Possession (PoP) of the private key. Next, the new certificate request message is sent to the certification authority for processing.
  • CRMF public certificate request message
  • a new digital certificate containing the detailed information in the certificate request message is issued to the end user through the subscriber's computer.
  • the subscriber's computer generates a protected confirmation message to complete the procedure.
  • the subscriber's computer verifies the accuracy of the new digital certificate. This verification determines the integrity of the new digital certificate and the period of validity. If a validation authority is available through an Online Certificate Status Protocol (OCSP) service, then the certificate revocation status can also be validated.
  • OCSP Online Certificate Status Protocol
  • the subscriber's computer reads one or more digital certificates already stored in the HCD to determine if the action required by the user is supported by one of said digital certificates. If the use of the necessary password to carry out this action is already supported by one of the existing digital certificates, the process ends. Otherwise, a new digital certificate is requested with a new use of password and / or a new field.
  • the public key stored in the HCD extracted by the subscriber's computer can be stored in a public access area or in a private access area. Depending on the current storage method for the public key, the extraction process differs. If the public key is stored in a public access area, the subscriber's computer extracts it directly and continues with the generation of the certificate request message requesting a new use or password field. If the public key is stored in a private access area, the user will be asked to enter his PIN or password to obtain a digital certificate that allows the extraction of the public key.
  • the public key extracted from the HCD can be stored in memory without a protection mechanism. If the public key is modified by an attacker before the certificate request message has been created, the subscriber's computer will detect this modification before confirming the process.
  • CMC Management of
  • CMS Cryptographic Message Syntax
  • Cryptographic Message Syntax describes an encapsulation syntax for data protection and is used to sign, encrypt, authenticate, or digitally encode arbitrary message content.
  • each message sent between an end user and a certification authority will be signed with the private key of the corresponding entity to ensure the integrity and authenticity of the messages exchanged.
  • CMC defines two different types of requests and responses: a "complete” and a "simple" PKI request / response.
  • the cryptographic module 212 described herein uses the complete PKI request.
  • the complete PKI request whose main body is PKI Data, is encapsulated either in a SignedData field or in an AuthenticationData field to ensure its integrity and / or authentication.
  • the PKI Data ASN.1 structure is:
  • PKIData:: SEQUENCE ⁇
  • control sequence is a sequence of controls that defines the actions that the PKI Request needs to perform.
  • reqSequence is a sequence of certificate request messages.
  • cmsSequence is a sequence of CMS message objects.
  • otherMsgSequence is a sequence of arbitrary data objects.
  • This object data refers to one or more controls.
  • PKI Answers there are two types of PKI Answers, simple and complete. The choice of type depends on the success or failure of the application and is made by the certification authority. If the request is successful, the certification authority will use a simple PKI Response. However, if any failure occurs, the certification authority will either use a full PKI Response or choose not to return anything. Therefore, the cryptographic module will treat both types depending on the certification authority.
  • a simple PKI Response consists of a SignedData message without EncapsulatedContentlnfo and without Signerlnfo.
  • the certificates requested in the Application PKI's are returned in the SignedData certificate field.
  • the certification authority includes all the certificates necessary to form complete certification paths. This simple PKI Response can be used by the certification authority since it is not necessary to include an identity check (the identity of the end user is tested indicating whether the digital certificate has already been issued for the public key embedded in the request).
  • a complete PKI Response consists of a SignedData or an AuthenticationDataencapsulated in a PKIResponse structure. In this situation, the certificates issued in the response are returned in the SignedData certificate field.
  • the type of content used in the full PKI Response is the PKI Response, whose ASN.l structure is:
  • the PKI Response fields have the same meaning as the PKI Data described here.
  • Each PKI Data or PKI Response element has an associated identifier, and all of them are encoded in the cerREqlds field of CertReqMsg objects (in the CRFM). This identifier is unique in the same PKI Data / Response.
  • the Body PartID value of 0 is reserved for use as the reference to the current PKI data object.
  • the Extended CMC Status Information control will also use these identifiers to refer to elements in the previous PKI Data / Response. Using this approach, the system maintains control over any errors that occur.
  • TaggedAttribute The structure of TaggedAttribute is as follows:
  • TaggedAttribute SEQUENCE ⁇ bodyParteID BodyPartlD,
  • AttrType is the
  • Object Identifier that identifies the control, and attrValues represents the data values used in the corresponding control.
  • not all controls will be necessary.
  • controls related to identity protection are not used in certain embodiments since the cryptographic module is renewing an existing certificate.
  • a renewal is similar to other certification requests except that identity verification is provided by existing certificates from a trusted certification authority.
  • identity verification is provided by existing certificates from a trusted certification authority.
  • EncryptedPOP and DecryptedPOP Another example of controls that may not be necessary in certain implementations is EncryptedPOP and DecryptedPOP, whose function is to provide the Proof-of-Possession of the end user's key pair to the certification authority.
  • CMCStatusInfo returns information about the status of a request / response from a client / server.
  • CMC Extended Status Information provides:
  • CMCStatusInfoV2 SEQUENCE ⁇
  • bodyList SEQUENCE SIZE (1..MAX) OF BodyPartReference, statusString UTF8String OPTIONAL,
  • the CMCStatus field contains the status value. You have several options that represent the success or failure of a specific operation.
  • CMCStatus :: INTEGE ⁇
  • the bodyList field identifies the controls to which the status value applies. If there is an error, the field is the bodyPartID choice of BodyPartReference with the value 1.
  • the satusString field can be omitted in certain implementations, such as when the additional description information it gives is not necessary.
  • the otherlnfo field contains additional information that expands that indicated in the CMC status code returned. Its structure is:
  • CMCFailInfo :: INTEGER ⁇
  • the pendlnfo field is used when the cMCStatus was either pending or partial. It contains information about when and how the client should request the result of this request.
  • extendedFailInfo is presented when the cMCStatus has failed and includes information about the detailed error.
  • TransactionID is a Transaction Identifier control that identifies a given transaction. Each request and response that belong to the same transaction includes the same value for this control.
  • SenderNonce and RecipientNonce protect against repeated attacks. These controls work as follows: In the first message of a transaction the Sender Nonce is included by the end user. The receiving certification authority reflects this value back to the issuer as a Recipient Nonce control and includes a new value as its Sender Nonce control. The end user then compares the value of the Recipient Nonce received with their own Sender Nonce and, if they match, it is accepted.
  • RecipientNonce:: OCTET STRTNG ConfirmCertAcceptance is a control that manages the confirmation of certificates issued by the certification authority and allows the process confirmation stage.
  • the certification authorities require a positive confirmation that the certificates issued to the end user are acceptable.
  • the CMCCertID structure contains the issuer and serial number of the certificate that is accepted.
  • CMCCertld :: IssuerAndSerialNumber
  • the confirmation stage is carried out as follows: the certification authority selects the confirmRequired option as CMC Status Information in a PKI Response, then the customer returns a Confirmation Certificate Acceptance control in a Complete PKI Request. Finally, the certification authority returns a PKI Response again with an extended extended CMC Status Information.
  • CMRF Certification Request Options.
  • CMRF certification requests
  • TaggedRequest structure is as follows:
  • BodyPartID BodyPartID
  • requestMessage I evaluated ANY DEFINED BY requestMessageType
  • tcr refers to the use of PKCS # 10 syntax
  • cmr refers to the use of CRMF syntax
  • orm is an externally defined certification request.
  • the cryptographic module uses the crm option when using the Certification Request Message Format (CRMF).
  • CRMF Certification Request Message Format
  • CMS Cryptographic Message Syntax
  • BodyPartID BodyPartID
  • bodyPartID is an integer that identifies this content information object and contentlnfo is the corresponding Contentlnfo object.
  • Contentlnfo encapsulates a single type of identified content that is capable of providing additional encapsulation (SignedData).
  • SignedData is used to wrap PKI data to ensure its security and is a substitute for the Proof-of-Possession for the corresponding public key. This PoP is carried out in each application, and is included in the CRMF structure.
  • the type of signed data content consists of content of any type and zero or more signature values.
  • the structure of SignedData ASN.l is:
  • the meaning of the SignedData fields includes the version that is the number of version. Its calculation depends on certificates, and econtentType fields, and Signerlnfo.
  • the digestAlgorithm is the identifier of the encryption algorithm and encapContentInfo is the signed content. It consists of an EncapsulatedContentInfo whose structure is:
  • EncapsulatedContentInfo :: SEQUENCE ⁇
  • eContentType is an object identifier and eContent is the content itself.
  • Embodiments of the cryptographic module will use this field when no external signature is used.
  • certificates is the collection of certificates necessary to certify the path from a certifying root certification authority to the signer in the signerlnfos field.
  • signerlnfos is a collection of signer information stored in the Signerlnfo structure.
  • the Signerlnfo fields have the following meaning: version is the syntax version number and depends on the choice of the Signerldentifier. In a particular implementation, its value is 3 because the cryptographic module will use the subjectKeyldentifier choice of the Signerldentifier structure. sid specifies the signer's certificate and therefore the signer's public key, which is required by the recipient to verify the signature. The signerldentifier provides two options for specifying the public key, but the cryptographic module will typically use the subjectKeyldentifier's choice to identify the signer's certificate by means of a key identifier. digestAlgorithm identifies the message encryption algorithm. This message encryption is calculated on the content along with the signed attributes.
  • signedattrs is a collection of attributes and is used, for example, when the EncapsulatedContentlnfo is not id-data.
  • This field contains at least two attributes: content-type has the content type of the EncapsulatedContentlnfo and message-digest has the content message encryption.
  • signatureAlgorithm identifies the signature algorithm, the signature is the result of the digital signature generation using the message encryption and the signer's private key, and UnsignedAttrs are omitted.
  • the SignedData structure is used to provide authentication and integrity to the PKI request by signing the PKI Data.
  • a Proof-of-Possession is used: Signature, Key Encypherment and Key Agreement. Therefore, a certificate stored in the Cryptographic Hardware Device (HCD) will typically be one of these three types.
  • HCD Cryptographic Hardware Device
  • the key pair has the associated signature purpose
  • the signature that wraps the PKI Data can be generated directly. Otherwise, if the end user has any of the other two types of certificates, the signature cannot be generated directly. In this situation, another process is carried out to allow the generation of a signature using the private key material of an embedded signature certification request, that is, included in the tcr or crm field of the Tagged equest.
  • BodyPartID BodyPartID
  • bodyPartID is the identifier for this object
  • otherMsgType is the Object Identifier of the message body type
  • otherMsgValue is the information.
  • Fig. 5 represents an example of an exchange 500 between an end user and a certification authority (CA).
  • CA certification authority
  • fig. 5 shows the messages exchanged between the end user and the CA divided into the three states: Certificate request, Certificate issuance and Confirmation.
  • the cryptographic module creates a CRMF message, which includes the certificate request information and the Proof-of-Possession (PoP) of the private key using in-band mechanisms available for CRMF.
  • PoP Proof-of-Possession
  • CRMF ASN.l The structure of CRMF ASN.l is as follows:
  • CertReqMessages :: SEQUENCE SIZE (1..MAX) OF CerReqMsg
  • CertReqMessages is a sequence of an element of CertReqMsg.
  • the reglnfo field does not apply in these embodiments since information related to the context of the certificate request is provided in the certReq field, and communication with a Registration Authority that could include additional information is not supported.
  • certificate request information (certReq field) and information related to the Proof-of-Possession (popo field).
  • certTemplate CertTemplate - Selected fields of the cert to be issued controls Controls OPTIONAL ⁇ - Attributes that affect the emission when the control field is not applied, certReqID is filled in by the cryptographic module with the coded Body Part Identifiers, and certTemplate is the structure that defines all the information that can be included in the certificate request:
  • the period of validity must be less than 1 hour, with notBefore equal to CurrentTime + 1 minute and NotAfter equal to CurrentTime + 1 hour.
  • the application may provide a period of validity. Otherwise, this field must be left empty.
  • the end user is asked about the period of validity for which they want to request the certificate.
  • the subject field is completed by the cryptographic module with the subject Distinguished ⁇ ame (DN) of the certificate stored in the HCD and extracted by the cryptographic module.
  • the publicKey field is completed by the cryptographic module with the public key included in the certificate stored in the HCD and extracted by the cryptographic module.
  • issuerUID and subjectUID are omitted, extensions are filled in by the cryptographic module with new necessary uses / key fields and with the Subject Key Identifier extension if necessary. This last extension is necessary to sign the PKI Data if the end user does not have a digital certificate for the purpose of signing.
  • the cryptographic module will add, as an extension in the CertTemplate structure, the keyUsage / field necessary for the operation being performed and if the Subject Key Identifier extension is necessary (when the key pair does not have a digital certificate for the signature purpose).
  • the KeyUsage data structure is:
  • Id-ce-keyUsage OBJECT IDENTIFIER ⁇ 2 5 29 15 ⁇
  • nonrepudiation (1) (in certain embodiments, this bit may be renamed to contentCommitment)
  • Extension structure will have the following values:
  • extnID equal to id-ce-keyUsage object identifier.
  • extnValue corresponds to the encoded structure of ASN.l DER of the previous KeyUsage structure.
  • the keyUsage value will be selected depending on the needs of the Application
  • the Subject Key Identifier extension provides a mechanism to identify certificates that contain a particular public key:
  • the CA is authorized to modify Any requested field.
  • the returned certificate needs to be checked by the applicant to see if the fields have been configured in an acceptable manner.
  • the CA typically uses template fields if possible.
  • PoP Proof-of-Possession
  • the specified high-level purposes cover encryption, digital signature and / or key agreement.
  • the request made by the end user could have more than one purpose.
  • the public key is a multipurpose key, the following priorities apply:
  • the encryption method described below is used.
  • the encryption method selected should be supported by the CA. Otherwise, and if the requested public key contains a digital signature purpose, then the end user follows the signature method described below. Finally, if neither of the above two purposes is requested, and the public key is for key agreement purposes, the key agreement method is used.
  • the data structure for the PoP in such a standard is as follows:
  • the CA has three different methods: The private key can be provided to the CA, a challenge encrypted from the CA can be decrypted (direct method), or the created certificate can be returned encrypted and used as the challenge response (indirect method)
  • the protocol does not support the provision of the private key or the indirect method. Therefore the direct method is used.
  • the general ASN.l structure for the key encipherment keys is:
  • POPOPrivKey :: CHOICE ⁇
  • the dhMAC value must be calculated based on RFC 2875 for Proof-of-Possession of static DH.
  • the SubsequentMessage field is challengeResp since the other methods are not supported.
  • the value of the SubsequentMessage is challengeResponse, which indicates that the CA sends a challenge to the end user and they need to decipher it and generate a correct response. Then, if the answer is correct, the CA will issue and send the new digital certificate to the end user.
  • publicKeyMAC contains a MAC based on a password over the value
  • the cryptographic module is associated with the third case, that is, "the subject of the certificate puts its name in the Certificate Template structure together with the public key. In these cases the poposklnput is omitted from the POPOSigningKey structure.
  • the signature field is calculated on the template structure of the encoded DER certificate.
  • the public key used by the current CA to verify the Proof-of-Possession is already certified in a certificate issued by a CA that belongs to another PKI (called, for example, PKI l).
  • PKI l A trust relationship is assumed between the PKI and the PKI to which the current CA belongs (PKI 2). Therefore, the registration / certification mechanism is applied as if the user had prior contact with the PKI 2 CA.
  • the cryptographic module verifies the signature of the certificate issued by the CA (confirmation stage). It is assumed that the corresponding CA certificate is known and can be used by the cryptographic module.
  • both sides will establish a shared secret key.
  • the methods to accomplish this task are the direct method, already explained before, and share a secret with the CA and use its value to generate MAC information.
  • the POPPrivKey field used for the key agreement is agreeMAC that contains the MAC value calculated by the shared secret.
  • CPS Certification Practice Statement
  • CPS does not constitute a contract or bind PKI participants. Therefore, in most cases it is necessary to include a separate document that incorporates part of the CPS references to create a contractual relationship between the parties.
  • the Certificate Policy is a set of rules, requirements and standards imposed by the PKI regarding the different issues.
  • the CP establishes which participants should do what and applies to multiple CAs, organizations and domains. Additionally, the CPS declares how a CA and other participants behave in a certain domain, that is, it is applied to a single CA, putting into practice all the procedures to satisfy the CP requirements.
  • the CA that receives the request for the new KeyUsage / field information is not the same or is not included in the same PKI as the CA that previously certified the cryptographic key pair.
  • the end user needs knowledge of the CPS of both PKI to maintain the security level and perform the necessary aspects that their corresponding protocols need.
  • the CP should identify a set of applications or uses to certify and establish the level of security for them. You can then submit the appropriate PKI requirements for those applications / users.
  • the PKI supports security services to provide Identification, Authentication, and Integrity through Proof-of-Possession processes, such as digital signatures and key exchanges.
  • Security levels define the behavior of CAs with respect to the identification of certificate recipients, and the issuance, management and revocation of such certificates.
  • a CPS indicates how a CA establishes security.
  • a CA can implement the CP at different levels of security. The choice of security level will depend on the Proof-of-Possession process that is being used each time the signature, encryption or key agreement is requested.
  • the validity period of the certificate of the new digital certificate will depend on the security PKI levels chosen for the application and on the required KeyUsage / field. For example, the security and validity period for the digital signature should not be the same as for the encryption of the key or key agreement.
  • the challenge with the period of validity of the certificate is the issuance of the digital single-use certificate (OTDC).
  • OTDC digital single-use certificate
  • the period of validity should not be the same as a normal digital certificate.
  • the problem lies in the fact that the OTDC has a limited period of use, due to its own definition: When the HCD is disconnected, the OTDC will be "lost" along with all other data stored in the software cache. Therefore, the OTDC validity period does not need to be longer than the availability time, that is, the time during which it is stored in the software cache. Otherwise the CA will issue and manage many digital certificates when only the last or even none of them is necessary.
  • the cryptographic module will assign the same validity period to the CRMF as the period that had the digital certificate extracted. Additionally, if necessary (as with the OTDC) the cryptographic module will allow a different validity period to be assigned to the new digital certificate.
  • Proof-of-Possession is the method through which the user provides a guarantee of their identity. Depending on what keyUsange / field information is required, the Proof-of-Possession method differs, but the result is that the user proves his identity to the CA. In particular embodiments, the Proof-of-Identity is made using online methods.
  • the Cryptographic Hardware Device (HCS) 216 is the physical medium in which the key pair is embedded and that it contains the digital certificate with the different KeyUsages of the corresponding public key.
  • An example of HCD is an electronic card, which is any card with embedded integrated circuits that can process data and logic programs. There are different categories of electronic cards:
  • Memory cards which contain only non-volatile memory storage components and sometimes some specific security logic.
  • Microprocessor cards which contains microprocessor components in addition to memory components. The microprocessor allows the card to perform different functions and use different applications.
  • Cryptographic cards are advanced microprocessor cards equipped with specialized cryptographic hardware that can perform cryptographic operations.
  • Cryptographic cards are equipped with specialized cryptographic hardware that allows the use of algorithms such as RSA and DSA. These cards are also capable of generating key pairs on the card, thereby avoiding the risk of having more than one copy of the key.
  • the main use of the electronic card is for digital signature and secure identification purposes.
  • Another embodiment is used to identify its owner without a doubt in an electronic environment. This identification is made by providing the Digital Identity Card (Id-Card) with cryptographic tools and certificates that make it possible to perform various cryptographic processes, such as the digital signature.
  • Id-Card Digital Identity Card
  • a specific embodiment refers to the Spanish Id-Card (electronic DNI (e-DNI)) that provides the following characteristics:
  • the e-DNI has an EEPROM with 34 Kbytes of capacity.
  • the information on the chip is distributed in three different zones with different access permissions. It has a public zone, a private zone and a safe zone. User permissions for each zone are different.
  • the invention may also include a number of functions to be performed by a computer processor, such as a microprocessor.
  • the microprocessor can be a specialized or dedicated microprocessor that is configured to perform particular tasks according to the invention, executing a machine-readable software code that defines the particular tasks performed. for the invention
  • the microprocessor can also be configured to operate and communicate with other devices such as direct memory access modules, memory storage devices, Internet-related hardware, and other devices that refer to the transmission of data according to the invention.
  • the software code can be configured using software formats and programming languages such as Java, C ++, XML (Extensible Dialing Language) and other languages that can be used to define functions that refer to device operations required to carry the practice the functional operations related to the invention.
  • the code can be written in different shapes and styles, many of which are known to those skilled in the art. Different code formats, code configurations, styles and forms of software programs and other means of configuration code to define the operations of a microprocessor according to the invention will not go outside the spirit and framework of the invention.
  • Cache devices are often included in such computers for use by the central processing unit as a storage position that is frequently stored and retrieved.
  • persistent memory is also frequently used by such computers to maintain information that is frequently retrieved by the central processing unit, but which are not often altered within persistent memory, as opposed to cache memory.
  • the main memory is also usually included to store and retrieve greater amounts of information such as data and software applications configured to perform functions according to the invention when executed by the central processing unit.
  • These memory devices can be configured as random access memory (RAM), static random access memory (SRAM), dynamic random access memory (DRAM), flash memory, and other memory storage devices that can be accessed by a central processing unit to store and retrieve information.
  • RAM random access memory
  • SRAM static random access memory
  • DRAM dynamic random access memory
  • flash memory and other memory storage devices that can be accessed by a central processing unit to store and retrieve information.
  • RAM random access memory
  • SRAM static random access memory
  • DRAM dynamic random access memory
  • flash memory and other memory storage devices that can be accessed by a central processing unit to store and retrieve information.
  • these memory devices are transformed to have different states, such as different electrical charges, different magnetic polarity, and the like.
  • the systems and methods configured according to the invention as described herein allow the Physical transformation of these memory devices.
  • the invention as described herein is directed to new and
  • embodiments of the system and method described herein facilitate the use of cryptographic keys. Additionally, some embodiments may be used in conjunction with one or more traditional devices, such as computing devices. For example, one embodiment can be used as an improvement of existing computing devices and / or communication devices.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Storage Device Security (AREA)

Abstract

Sistemas y métodos para usar claves criptográficas, leer un certificado digital existente desde un dispositivo hardware criptográfico y extraer una clave pública desde el certificado digital existente. Se genera un mensaje de solicitud de certificado que identifica un nuevo uso y/o campo de certificado asociado con la clave pública. El mensaje de solicitud de certificado es firmado y comunicado a una autoridad de certificación. Un nuevo certificado digital es recibido procedente de la autoridad de certificación que incluye el nuevo uso/campo. El nuevo certificado digital es a continuación aplicado a operaciones criptográficas, tales como procedimientos de firma, procedimientos de cifrado y así sucesivamente usando el par de claves existentes.

Description

STSTFMAS V MÉTODOS PARA TTSAR CT AVFS CR TPTOCR Á FTC A S
OB.TFTO fiF T A TNVFNCTÓN
El invento se refiere generalmente a sistemas y métodos para usar y volver a usar claves criptográficas con distintos propósitos. En particular, los sistemas y métodos descritos permiten que un usuario vuelva a utilizar un par de claves criptográficas con propósitos que son diferentes de los propósitos bajo los cuales las claves fueron emitidas inicialmente, o asociar información diferente/adicional, por ejemplo, campos de un certificado con la identidad digital del propietario del par de claves.
FSTAfiO TW T A TFCNTCA
Ciertos sistemas criptográficos usan dos claves, denominadas como una clave pública y una clave privada. La clave pública es conocida públicamente y la clave privada es conocida solo por un usuario particular. Un mensaje u otros datos son cifrados usando la clave pública y posteriormente descifrados por el receptor usando su clave privada. Las claves pública y privada están relacionadas de una manera que permite a la clave pública cifrar un mensaje de tal modo que solamente la clave privada relacionada pueda descifrar el mensaje. Cualquiera que conozca la clave pública de un usuario particular puede enviar un mensaje cifrado a ese usuario con una certeza sustancial de que solamente el receptor pretendido será capaz de acceder al contenido del mensaje. Este tipo de cifrado es popular cuando se comunican mensajes y otros datos a través de redes públicas, tales como Internet. La operación criptográfica puede ser invertida, en el sentido de que la clave privada puede ser usada en primer lugar para cifrar un valor resumen criptográfico o "hash" del mensaje, empleando posteriormente la clave pública para descifrarlo. Ciertos esquemas de firma digital usan este modo de operación. Así, la autenticación del origen de los datos y la integridad de los datos están asegurados, ya que el origen es el único que conoce la clave privada y cualquier modificación del mensaje firmado es detectada.
La infraestructura de clave pública (PKI) fue diseñada para permitir el uso de una criptografía de clave pública (PKC) en entornos abiertos e inseguros, y con un número ilimitado de usuarios potenciales. En la PKI, la clave pública está vinculada a una identidad mediante un certificado digital. Cuando una entidad u otro usuario verifica satisfactoriamente una firma digital usando la clave pública embebida en un certificado digital, la identidad del firmante es la contenida en el certificado digital. El emisor del certificado digital es denominado como Autoridad de Certificación (CA). En ciertas situaciones, hay varios niveles de CA. La CA en el primer nivel es denominada como la CA raíz. Una CA emite los certificados digitales de las entidades del nivel inferior, incluyendo posibles CAs subordinadas. Los certificados digitales de usuario final son emitidos por las CA que pertenecen al último nivel de la jerarquía.
Cada certificado digital es firmado digitalmente por el emisor correspondiente para asegurar la autenticidad de la información contenida en el certificado digital. Un certificado digital es válido si su integridad es mantenida (por ejemplo, la firma de la CA es verificada correctamente). La validez de un certificado digital puede también depender de un período de validez incluido dentro del certificado digital. El estado de un certificado digital es válido si el certificado digital no ha sido revocado o suspendido por el abonado o suscriptor u otra entidad autorizada. Por ejemplo, el certificado digital debería revocarse si la clave privada correspondiente es comprometida o el abonado sospecha que ha sido comprometida. Un certificado digital también debería revocarse o suspenderse si los propósitos para los que el certificado digital fue emitido no aplican. Por ejemplo, si un certificado digital fue emitido para que un empleado accediera a una red de empresa, el certificado digital deberá revocarse cuando el empleado se desvincule contractualmente de la empresa.
Cuando un certificado digital es revocado, su número de serie (único en la PKI concreta) es almacenado por la CA junto con el tiempo de revocación y el motivo de . Esta información se almacena típicamente en una lista de revocación de certificados (CRL). Cuando un certificado digital es revocado, la clave privada correspondiente ya no es útil, impidiendo por ello el uso inapropiado o malicioso de la misma. La relación entre el abonado y la CA se formaliza a través del uso de una declaración de práctica de certificación (CPS). La CPS establece los mecanismos y procedimientos seguidos por la CA para emitir y gestionar certificados digitales así como las obligaciones, responsabilidades y derechos del abonado que solicita un certificado digital. La CPS también describe el proceso de registro en el que el usuario es autenticado por una autoridad de registro (RA) antes de emitir el certificado digital. Durante este proceso de autenticación, el usuario proporciona información necesaria para crear el certificado digital. Esta información es autenticada por la RA usando una o más técnicas.
Los sistemas existentes a menudo emiten certificados digitales para un conjunto particular de usos (o propósitos), impidiendo por tanto el uso del certificado para usos no autorizados. En caso que el usuario necesite un certificado para un propósito que no está permitido por el certificado digital en curso o actual, deberá solicitar un nuevo certificado digital y repetir el proceso de registro y de emisión. Cuando se usan dispositivos de hardware para almacenar los pares de claves, se requiere un nuevo dispositivo hardware para almacenar el nuevo par de claves, requiriendo por ello que el usuario mantenga múltiples dispositivos de hardware. Si el usuario aplica el mismo PIN (Número de Identificación Personal) a cada uno de los múltiples dispositivos de hardware, el nivel de seguridad total puede verse disminuido.
BRFVF FNTTNCTADO DF T AS FT TTRAS
La fig. 1 representa un ejemplo de las entidades que intervienen en una infraestructura de clave pública (PKI), cómo pueden aplicarse los sistemas y métodos descritos aquí.
La fig. 2 representa un ejemplo de sistema capaz de poner en práctica los procedimientos descritos aquí.
La fig. 3 representa un diagrama de flujo de un procedimiento ejemplo para emitir un certificado digital.
La fig. 4 representa un diagrama de flujo de un procedimiento ejemplo para emitir un nuevo certificado digital.
La fig. 5 representa un intercambio ejemplo entre un usuario final y una autoridad de certificación (CA) para emitir un nuevo certificado digital.
A lo largo de toda la descripción, pueden usarse números de referencia similares para identificar elementos similares.
nFSCRTPCTÓN DF TTN MODO DF RFAT 17 ACTÓN
Los sistemas y métodos descritos aquí reutilizan claves criptográficas integradas en un dispositivo hardware criptográfico (HCD), tal como una tarjeta inteligente o una credencial de seguridad USB. Estos sistemas y métodos expanden la utilidad de la clave privada al tiempo que mantienen los requisitos de seguridad existentes. Como se ha descrito aquí, ciertas operaciones pueden requerir emitir una nueva clave pública para permitir usos adicionales de la clave o para añadir nuevos campos que permitan el uso del par de claves pública-privada en nuevas aplicaciones. Por ejemplo, el usuario puede hacer operar el HCD de forma normal, pero la clave pública mantenida en el HCD es extraída y un nuevo certificado digital con los nuevos usos de la clave (o nuevos campos) es solicitado a la autoridad de certificación apropiada (CA). Así, el usuario no necesita reemplazar su HCD existente, utilizando su par de claves pública-privada existente con los nuevos propósitos. La re-emisión de las claves criptográficas es transparente para el usuario. En particular, el usuario no necesita solicitar un nuevo par de claves con nuevos usos o campos, que requerirían que el usuario gestionara múltiples HCD. En vez de ello, el par de claves existentes es ampliado con los nuevos usos o campos mientras el HCD permanece sin cambios.
La fig. 1 representa un entorno 100 donde diferentes entidades de una infraestructura de clave pública (PKI) interactúan para aplicar los sistemas y métodos descritos aquí. El entorno 100 soporta la emisión de certificado digital así como la validación de certificado digital. Una autoridad de certificación (CA) 102 es accedida desde el sistema de abonado 104, un sistema 106 perteneciente al verificador de la posible firma digital o datos cifrados que reciba en una transacción iniciada con el sistema de abonado 104, una autoridad de registro (RA) 108, y una autoridad de validación (VA) 112. El sistema de abonado 104 es un ordenador u otro dispositivo capaz de realizar las tareas basadas en el abonado descritas aquí. El sistema de abonado 104 incluye un HCD 110 que almacena el par de claves pública-privada asociado con el abonado. El HCD 110 es cualquier tipo de dispositivo hardware capaz de almacenar pares de claves pública-privada como se ha descrito aquí. Los HCD ejemplares incluyen tarjetas inteligentes, credenciales de USB (Bus en Serie Universal), y similares. El HCD 110 puede también almacenar otros datos usados por el abonado. El sistema 106 perteneciente al verificador es un ordenador u otro dispositivo capaz de realizar las tareas basadas en la verificación de firmas digitales o descifrado de datos descritas aquí. Un abonado solicita un certificado digital presentando credenciales a la autoridad de registro 108 para probar la identidad del abonado. Este proceso de identificación puede ser realizado de modo remoto usando métodos en línea o presencialmente, tales como la identificación física de la persona mediante un documento nacional de identidad del abonado. En la realización de la fig. 1, la autoridad de registro 108 comunica una información de abonado validada a la autoridad de certificación 102. En determinadas implementaciones concretas, las actividades de la autoridad de registro 108 y de la autoridad de certificación 102 pueden realizarse por la misma entidad. En otros casos, estas actividades pueden realizarse por dos o más entidades diferentes.
La generación apropiada del par de claves pública-privada es importante para asegurar un elevado nivel de seguridad dentro del entorno 100. Los pares de claves pueden ser generados usando una aplicación software instalada en el sistema 104 del abonado. En otra puesta en práctica, la autoridad de certificación 102 puede generar pares de claves usando componentes de software y/o hardware, que típicamente proporcionan un mayor nivel de seguridad en el proceso de generación del par de claves. El proceso de registro del abonado en la autoridad de registro 108 es también importante para la seguridad dentro del entorno 100.
Después de que el abonado haya sido identificado y autenticado apropiadamente, la autoridad de certificación 102 genera un certificado digital para dicho abonado. El certificado digital incluye información proporcionada por la autoridad de registro 108, la clave pública y otros parámetros que dependen del perfil de certificado y de la declaración de práctica de certificación (CPS). La autoridad de certificación 102 proporciona a continuación el certificado digital al abonado. Si el par de claves es generado por la autoridad de certificación 102, a continuación el abonado también obtiene la clave privada de la autoridad de certificación 102 a través de Internet o físicamente en la ubicación de la autoridad de certificación. En una realización particular, el certificado digital y la clave privada son almacenados en una aplicación de software. Si la clave privada es emitida con propósitos de no repudio, la autoridad de certificación 102 no almacena una copia de la clave privada después de la distribución al abonado.
Un certificado digital es una colección de información referida a la identidad del abonado, la clave pública asociada con dicha identidad, y la identidad del emisor. El certificado digital también incluye un número de serie que identifica de modo único el certificado digital dentro de la infraestructura de clave pública. Los certificados digitales también incluyen información relativa al período de validez del certificado digital y los propósitos/aplicaciones para los que el abonado puede usar la clave privada asociada con la clave pública que está contenida en el certificado digital. Así, un certificado digital particular es emitido para un subconjunto específico de propósitos, pero no generalmente para todos los propósitos. Los propósitos ejemplares incluyen firmas digitales, cifrado de datos, confirmación de clave, y firma del certificado (corrientemente denominadas como "operaciones criptográficas").
Cuando se validan mensajes u otros datos recibidos, el verificador usa la lista de revocación de certificados (CRL) para asegurarse de que el certificado digital no ha sido revocado. El sistema 106 del verificador puede realizar por si mismo la validación del mensaje recibido o puede solicitar la validación del mensaje recibido por una autoridad de validación (VA) 112. La autoridad de validación 112 también usa la CRL obtenida de la autoridad de certificación 102 para validar los certificados digitales solicitados por el verificador.
El proceso de validación realizado por la parte que confía o una autoridad de validación valida el certificado digital (por ejemplo, para asegurar que no ha sido revocado). El certificado digital no es válido si, por ejemplo, ha sido revocado. La parte que confía o una autoridad de validación pueden también validar datos criptográficos (por ejemplo, firma digital, mensaje cifrado, etc.) usando el certificado digital del firmante. En este caso, el verificador o la autoridad de validación también validan el propósito para el que se está usando el certificado. El certificado no es válido si se está usando para un propósito no autorizado.
Como se ha mencionado antes, los sistemas y métodos descritos aquí permiten la reutilización del mismo par de claves publica-privada con propósitos (o con campos) que son diferentes de los que se tenían cuando el par de claves fue creado originalmente. La fig. 2 representa un sistema ejemplar capaz de poner en práctica los procedimientos descritos aquí. Un ordenador de abonado 202 es capaz de comunicarse con la autoridad de certificación 102 y la autoridad de registro 108. El ordenador de abonado 202 puede ser cualquier tipo de dispositivo informático capaz de realizar las operaciones descritas aquí. Por ejemplo, el ordenador de abonado 202 puede ser un ordenador de sobremesa, un ordenador portátil, un ordenador manual, un teléfono inteligente, una consola de juegos, un descodificador, y similares.
El ordenador del abonado 202 está acoplado a un dispositivo hardware criptográfico (HCD) 216 a través de un bus en serie universal (USB) u otro enlace de comunicación. Como se ha mencionado aquí, las realizaciones particulares del HCD 216 incluyen una tarjeta inteligente o una credencial de USB. En otras realizaciones, el HCD 216 puede ser cualquier tipo de dispositivo capaz de almacenar datos e interactuar con el ordenador del abonado 202 como se ha descrito aquí. Realizaciones particulares del HCD 216 incluyen una EEPROM (Memoria Sólo para Lectura Programable que se puede Borrar Eléctricamente) para almacenar datos. El HCD 216 típicamente tiene limitado el espacio de almacenamiento y puede no permitir el almacenamiento de nuevos datos dentro del HCD después de que el par de claves pública-privada inicial y los datos relacionados sean almacenados dentro del HCD. Otras realizaciones del HCD 216 permiten el almacenamiento de nuevos certificados digitales y las claves correspondientes si hay espacio disponible dentro del HCD. En una realización particular, el HCD 216 es insertado en un lector de tarjetas u otro dispositivo acoplado al ordenador del abonado 202.
El ordenador del abonado 202 incluye un procesador 204, un dispositivo de almacenamiento 206, y un módulo de comunicación 208. El procesador 204 realiza distintas operaciones necesarias durante el funcionamiento del ordenador del abonado
202. Por ejemplo, el procesador 204 realiza varios procedimientos y métodos descritos aquí para crear, manejar, y procesar diferentes datos criptográficos e información relacionada.
El dispositivo de almacenamiento 206 almacena datos y otra información usada durante el funcionamiento del ordenador del abonado 202. El dispositivo de almacenamiento 206 puede incluir una o más memorias volátiles o no volátiles. En una realización particular, el dispositivo de almacenamiento 206 incluye una unidad de disco duro así como memorias volátiles y no volátiles. El módulo de comunicación 208 comunica datos entre el ordenador del abonado 202 y otros dispositivos, tales como la autoridad de certificación 102 y la autoridad de registro 108.
El ordenador del abonado 202 también incluye una aplicación 210, un módulo criptográfico 212, y una unidad de hardware criptográfica 214. Estos tres componentes (210, 212, y 214) de ordenador del abonado 202 pueden ser denominados como diferentes "capas" del sistema. La aplicación 210 es una aplicación de software que hace uso de los sistemas criptográficos y métodos descritos aquí cuando comunica datos o realiza otras tareas que usan claves criptográficas. Ejemplos de la aplicación 210 incluyen aplicaciones basadas en la web, plataformas de correo electrónico, aplicaciones para la creación de firma, y similares. El módulo criptográfico 212 funciona en una capa inferior (por ejemplo, por debajo de la aplicación 210) y comunica con el HCD 216 a través de la unidad de hardware criptográfica 214. En algunas realizaciones, el módulo criptográfico 212 maneja la comunicación de datos hacia y desde la autoridad de certificación 102. La unidad de hardware criptográfica 214 comunica directamente con el HCD 216, por ejemplo para recuperar la clave pública y otra información accesible almacenada en el HCD 216.
Los sistemas y métodos descritos aquí permiten que una clave pública sea emitida de nuevo con propósitos adicionales y/o para campos de certificado adicional/diferente. El ordenador del abonado 202 soporta la nueva emisión de claves públicas como se ha descrito aquí. En una realización particular, el HCD 216 almacena una clave privada de una forma segura y permite el acceso al certificado digital que "envuelve" la clave pública correspondiente. El acceso al certificado digital y su recuperación pueden ser protegidos opcionalmente usando un PIN o una contraseña. El acceso a la clave privada es protegido mediante el uso de un PIN o contraseña. El uso de la clave pública es definido por distintas extensiones de certificado digital, alguna de las cuales se han descrito aquí. En algunas realizaciones, el uso de la clave pública incluye todos los usos de clave estandarizados (por ejemplo, todos los propósitos).
Durante el uso normal del HCD 216, el usuario puede necesitar realizar una operación criptográfica que no está apoyada por los usos/campos corrientes asociados con la clave pública almacenada en el HCD. Por ejemplo, una aplicación de correo electrónico puede requerir un certificado digital que incluye un campo de correo electrónico. Si el certificado digital existente almacenado en el HCD 216 no incluye un campo de correo electrónico, es necesario un nuevo certificado digital para permitir que la aplicación de correo electrónico realice su función designada.
La fig. 3 representa un diagrama de flujo de un procedimiento ejemplar 300 para emitir un certificado digital. Mcialmente, un módulo criptográfico (por ejemplo, el módulo criptográfico 212 en la fig. 2) intenta leer el certificado digital desde un dispositivo hardware criptográfico (por ejemplo HCD 216) en el bloque 302. Si el acceso al certificado digital está protegido por un PIN/contraseña, entonces el módulo criptográfico solicita el PIN o contraseña al usuario del sistema, tal como el abonado (bloque 304). Esta operación es opcional - ciertos sistemas pueden no requerir un PIN o contraseña para acceder al certificado digital.
A continuación, el módulo criptográfico extrae la clave pública del certificado digital y genera un mensaje de solicitud de certificado medianteCRMF (Formato de Mensaje de Solicitud de Certificado) e identificando el nuevo uso deseado (bloque 306). El mensaje de solicitud de certificado es firmado por el usuario del sistema (bloque 308) teniendo el usuario que introducir el PIN o contraseña apropiado. El mensaje de solicitud de certificado es a continuación enviado a una autoridad de certificación (por ejemplo, autoridad de certificación 102) para la emisión de un nuevo certificado digital (bloque 310). La autoridad de certificación es seleccionada basándose en el contexto de aplicación específico, tal como una aplicación de correo electrónico que desea un certificado digital que incluye un campo de correo electrónico, como se ha descrito antes. La autoridad de certificación seleccionada debería ser capaz de procesar solicitudes de CRMF y emitir certificados digitales con el uso de la nueva clave solicitado en el mensaje de solicitud de certificado. En una realización particular, se ha incluido una "Proof-of-Possession" en el mensaje de solicitud de certificado usando mensajes transparentes para el usuario. La "Comprobación de Posesión" ("Proof-of-Possession") usada puede variar dependiendo de las políticas de la autoridad de certificación y/o de la autoridad de registro.
Después del tratamiento por la autoridad de certificación, el módulo criptográfico recibe el nuevo certificado digital (bloque 312). La operación criptográfica es a continuación realizada por el ordenador del abonado usando el nuevo certificado digital y el dispositivo hardware criptográfico (bloque 314). El usuario es requerido para que introduzca el PIN o contraseña con el fin de realizar la operación criptográfica. El nuevo certificado digital no es necesariamente almacenado en el dispositivo hardware criptográfico. En una realización, el nuevo certificado digital es usado una vez y desechado. Si se necesita un certificado digital similar en el futuro, se repite el procedimiento 300 para obtener un nuevo certificado digital. En otra realización, el nuevo certificado digital es almacenado dentro del dispositivo hardware criptográfico o almacenado en el ordenador del abonado 202 (por ejemplo, en el dispositivo de almacenamiento 206) para un uso futuro.
La fig. 4 representa un diagrama de flujo de un procedimiento ejemplar 400 para emitir un nuevo certificado digital. El nuevo certificado digital es emitido para usarlo durante una o más sesiones. En ciertas puestas en práctica, el nuevo certificado digital es borrado al final de cada sesión - si otro certificado digital es necesario en una sesión futura, es emitido un certificado digital diferente para usar durante esa futura sesión.
Inicialmente, el procedimiento 400 genera una solicitud para un nuevo certificado digital identificando un nuevo uso y/o campos adicionales o diferentes (bloque 402). El nuevo certificado digital es recibido de la autoridad de certificación (bloque 404) y la operación criptográfica es realizada usando el nuevo certificado digital (bloque 406). El procedimiento determina si el HCD tiene espacio para almacenar el nuevo certificado digital (bloque 408). Si hay espacio disponible en el HCD, el procedimiento almacena el nuevo certificado digital en el HCD (bloque 410).
Si el HCD no tiene espacio para almacenar el nuevo certificado digital, entonces el procedimiento determina si la sesión en curso ha finalizado (bloque 412). En una realización, una sesión permanece activa mientras el dispositivo hardware criptográfico está conectado al ordenador del abonado. Si la sesión no ha finalizado (es decir, la sesión está aun activa), el nuevo certificado digital permanece disponible para subsiguientes operaciones criptográficas (bloque 414). Cuando la sesión ha finalizado, el nuevo certificado digital es borrado (bloque 416). Si otra sesión es activada en el futuro requiriendo un certificado digital similar para un uso adicional, el procedimiento de la fig. 4 es repetido. El procedimiento 400 permite que un abonado añada nuevos usos/campos manteniendo el par de claves almacenado en un dispositivo hardware criptográfico existente en vez de reemplazarlo con un nuevo dispositivo que almacene un nuevo par de claves que soporte los nuevos usos/campos.
En una realización alternativa, el procedimiento de la fig. 4 es modificado para generar un certificado digital de un solo uso. Un certificado digital de un solo uso es emitido para usar durante una sesión particular, pero borrado al final de esa sesión. Si se necesita otro certificado digital en una sesión futura, es emitido un certificado digital de un solo uso diferente para usar durante la sesión futura. El certificado digital de un solo uso es almacenado, por ejemplo, en la RAM (Memoria de Acceso Aleatorio) o en un dispositivo de almacenamiento volátil similar en el ordenador del abonado. En una realización particular, una sesión permanece activa mientras el dispositivo hardware criptográfico está conectado al ordenador del abonado. Una sesión termina cuando el dispositivo hardware criptográfico es desconectado, provocando el borrado del certificado digital de un solo uso desde la RAM del ordenador del abonado u otro dispositivo de almacenamiento. Este procedimiento alternativo es similar al procedimiento de la fig. 4, exceptuando los bloques 408 y 410. Así, el nuevo certificado digital es usado durante la sesión en curso, y no es almacenado en el HCD, independientemente de si el HCD tiene espacio disponible para almacenar el nuevo certificado digital. El nuevo certificado digital es borrado al final de una sesión incluso si el HCD es capaz de almacenar el nuevo certificado digital.
Una puesta en práctica ejemplar de los sistemas y métodos descritos aquí proporciona medios para la protección de mensajes de correo electrónico. En esta puesta en práctica, los mensajes de correo electrónico son protegidos usando técnicas criptográficas aplicadas a través de software y/o hardware. Cuando se usan los métodos y sistemas descritos aquí, los mensajes de correo electrónico pueden ser protegidos sin requerir ninguna herramienta adicional o nuevo dispositivo hardware criptográfico que contenga un nuevo certificado digital que soporte la protección de mensajes de correo electrónico. Un certificado digital modificado que incluye el uso de la clave específica es solicitado y procesado como se ha descrito aquí.
En otra puesta en práctica ejemplar, el usuario envía mensajes de correo electrónico seguros en los que la identidad del usuario está asegurada por datos criptográficos, tales como una firma digital. En este ejemplo, el usuario sólo recibe mensajes de correo electrónico en los que la identidad del remitente del correo electrónico es autenticada por medio del certificado digital (por ejemplo, el campo de correo electrónico del certificado digital incluye la dirección de correo electrónico del remitente). Esta puesta en práctica elimina o reduce significativamente la cantidad de correo SPAM (correo electrónico voluminoso no solicitado) recibido por el usuario.
En una realización particular, la comunicación entre el ordenador del abonado 202 y la autoridad de certificación 102 usa el procedimiento siguiente. Inicialmente, el ordenador del abonado 202 extrae la clave pública contenida en el certificado digital embebido en el HCD 216. Una vez que la clave pública es extraída del HCD, el ordenador del abonado genera un nuevo mensaje de solicitud de certificado (en CRMF). Este mensaje solicita un uso de nueva clave (Uso de Clave) y/o nuevos campos de información (por ejemplo, un campo de CORREO ELECTRÓNICO). El nuevo mensaje de solicitud de certificado es protegido con varios métodos que verifican la Proof-of-Possession (PoP) de la clave privada. A continuación, el nuevo mensaje de solicitud de certificado es enviado a la autoridad de certificación para su tratamiento. Después de que la autoridad de certificación haya verificado el mensaje, incluyendo la PoP, un nuevo certificado digital que contiene la información detallada en el mensaje de solicitud de certificado es emitido al usuario final a través del ordenador del abonado. El ordenador del abonado genera un mensaje de confirmación protegido para finalizar el procedimiento. Antes de enviar el mensaje de confirmación protegido, el ordenador del abonado verifica la exactitud del nuevo certificado digital. Esta verificación determina la integridad del nuevo certificado digital y el período de validez. Si hay disponible una autoridad de validación a través de un servicio de Protocolo de Estado del Certificado en Línea (OCSP), entonces el estado de revocación del certificado puede ser también validado.
En una puesta en práctica particular del proceso de extracción de la clave pública, antes de extraer la clave pública, el ordenador del abonado lee uno o más certificados digitales ya almacenados en el HCD para determinar si la acción requerida por el usuario está soportada por uno de dichos certificados digitales. Si el uso de la clave necesaria para llevar a cabo esta acción está soportado ya por uno de los certificados digitales existentes, el proceso finaliza. En caso contrario, se solicita un nuevo certificado digital con un nuevo uso de clave y/o un nuevo campo.
La clave pública almacenada en el HCD extraída por el ordenador del abonado puede ser almacenada en una zona de acceso público o en una zona de acceso privado. Dependiendo del método de almacenamiento actual para la clave pública, el proceso de extracción difiere. Si la clave pública está almacenada en una zona de acceso público, el ordenador del abonado la extrae directamente y continúa con la generación del mensaje de solicitud del certificado solicitando un uso o campo de clave nueva. Si la clave pública está almacenada en una zona de acceso privado, se le pedirá al usuario que inserte su PIN o contraseña para obtener un certificado digital que permita la extracción de la clave pública.
Cada vez que un nuevo certificado digital es emitido, su exactitud y validez son verificadas por el abonado (por ejemplo, a través del ordenador del abonado). Así, la clave pública extraída del HCD puede ser almacenada en la memoria sin mecanismo de protección. Si la clave pública es modificada por un atacante antes de que se haya creado el mensaje de solicitud de certificado, el ordenador del abonado detectará esta modificación antes de confirmar el proceso.
En una realización particular, un protocolo denominado CMC (Gestión de
Certificado sobre CMS (Sintaxis de Mensaje Criptográfico (CMS)) es usado cuando se ponen en práctica los sistemas y métodos descritos aquí. La Sintaxis de Mensaje Criptográfico (CMS) describe una sintaxis de encapsulado para protección de datos y es usada para firmar, cifrar, autenticar, o codificar digitalmente un contenido de mensaje arbitrario. En esta realización, cada mensaje enviado entre un usuario final y una autoridad de certificación será firmado con la clave privada de la entidad correspondiente para asegurar la integridad y autenticidad de los mensajes intercambiados.
CMC define dos tipos diferentes de solicitudes y de respuestas: una solicitud/respuesta de PKI "completa" y una "simple". En una realización particular, el módulo criptográfico 212 descrito aquí usa la solicitud de PKI completa. La solicitud de PKI completa, cuyo cuerpo principal son Datos de PKI, es encapsulada o bien en un campo de SignedData (Datos Firmados) o bien en un campo de AuthenticationData (Datos de Autenticación) para asegurar su integridad y/o autenticación.
En una realización, la estructura ASN.1 de Datos de PKI es:
PKIData : := SEQUENCE {
controlSequence SEQUENCE SIZE(0..MAX) OF TaggedAttribute,
reqSequence SEQUENCE SIZE(0..MAX) OF Tagged equest,
cmsSequence SEQUENCE SIZE(0..MAX) OF TaggedContentlnfo,
otherMsgSequence SEQUENCE SIZE(0..MAX) OF OtherMsg
}
Dónde la secuencia de control es una secuencia de controles que define las acciones que la Solicitud de PKI necesita realizar. reqSequence es una secuencia de mensajes de solicitud de certificado. cmsSequence es una secuencia de objetos de mensaje CMS. otherMsgSequence es una secuencia de objetos de datos arbitrarios.
Estos datos objeto están referidos a uno o más controles.
Como se ha mencionado antes, hay dos tipos de Respuestas de PKI, simple y completa. La elección del tipo depende del éxito o fracaso de la solicitud y es realizada por la autoridad de certificación. Si la solicitud tiene éxito, la autoridad de certificación usará una Respuesta de PKI simple. Sin embargo, si ocurre cualquier fallo, la autoridad de certificación usará o bien una Respuesta de PKI completa o bien elegirá no devolver nada. Por ello el módulo criptográfico tratará ambos tipos dependiendo de la autoridad de certificación.
Una Respuesta de PKI simple consiste en un mensaje SignedData sin EncapsulatedContentlnfo y sin Signerlnfo. Los certificados solicitados en la Solicitud de PKI son devueltos en el campo de certificado de SignedData. La autoridad de certificación incluye todos los certificados necesarios para formar trayectos de certificación completos. Esta Respuesta de PKI simple puede ser usada por la autoridad de certificación ya que no se necesita incluir una comprobación de identidad (la identidad del usuario final es probada indicando si el certificado digital ya ha sido emitido para la clave pública embebida en la solicitud).
Una Respuesta de PKI completa consiste de un SignedData o un AuthenticationDataencapsulated en una estructura de PKIResponse. En esta situación, los certificados emitidos en la respuesta son devueltos en el campo de certificados del SignedData.
El tipo de contenido usado en la Respuesta de PKI completa es la Respuesta de PKI, cuya estructura ASN.l es:
PKIResponse ::= SEQUENCE {
controlSequence SEQUENCE SIZE(0..MAX) OF TaggedAttribute,
cmsSequence SEQUENCE SIZE(0..MAX) OF TaggedContentlnfo,
otherMsgSequence SEQUENCE SIZE(0..MAX) OF OtherMsg
}
ReponseBody ::= PKIResponse
Los campos de la Respuesta de PKI tienen el mismo significado que los Datos de PKI descritos aquí.
Cada elemento de Datos de PKI o de Respuesta de PKI tiene un identificador asociado, y la totalidad de ellos están codificados en el campo cerREqlds de objetos de CertReqMsg (en el CRFM). Este identificador es único en los mismos Datos/Respuesta de PKI. El valor de PartID de cuerpo de 0 está reservado para usar como la referencia al objeto de datos de PKI en curso.
El control de Información de Estado de CMC Extendido usará también estos identificadores para referirse a elementos en los Datos/Respuesta de PKI previos. Usando esta aproximación, el sistema mantiene el control sobre cualesquiera errores que ocurran.
Los diferentes campos de Datos de PKI y de Respuesta de PKI descritos anteriormente son descritos en mayor detalle a continuación.
La estructura de TaggedAttribute es la siguiente:
TaggedAttribute: := SEQUENCE { bodyParteID BodyPartlD,
attrType OBJECT IDENTIFIE
attrValues SET OF AttributeValue
}
Cuando bodyPartID es un entero que identifica el control, attrType es el
Identificador de Objeto que identifica el control, y attrValues representa los valores de datos usados en el control correspondiente.
En la tabla siguiente se recoge el nombre, el identificador de objeto, y la estructura sintáctica para los controles definidos en el protocolo CMC:
Trient.ifica.rior Descripción OID Estructura. ASN.1
id- -cmc- -staruslnfo id- ■eme 1 CMCStatusInfo
id- -eme- -identification id-cme 2 UTF8String
id- -eme- -identityProof id-cme 3 OCTET STRING
id- ■eme- -dataReturn id- ■eme 4 OCTET STRING
id- ■eme- -transactionld id-cme 5 INTEGER
id- ■eme- -senderNonce id- ■eme 6 OCTET STRING
id- ■eme- -recipientNonce id- ■eme 7 OCTET STRING
id- ■eme- -addExtensions id- ■eme 8 AddExtensions
id- ■eme- -encryptedPOP id-cme 9 EncryptedPOP
id- ■eme- -decryptedPOP id-cme 10 DecryptedPOP
id- ■eme- -IraPOPWitness id- ■eme 11 LraPOPWitness
id- ■eme- -getCert id-cme 15 GetCert
id- ■eme- -getCRL id-cme 16 GetCRL
id- ■eme- -revokeRequest id- ■eme 17 RevokeRequest
id- ■eme- -reglnfo id-cme 18 OCTET STRING
id- ■eme- -responselnfo id- ■eme 19 OCTET STRING
id- ■eme- -queryPending id-cme 21 OCTET STRING
id- ■eme- -popLinkRandom id- ■eme 22 OCTET STRING
id- ■eme- -popLinkWitness id- ■eme 23 OCTET STRING id- -cmc- -popLinkWitnessV2 id- -eme 33 OCTET STRING
id- ■eme- -confirmCertAcceptance id- -eme 24 CMCCertld
id- ■eme- -statusInfoV2 id- -eme 25 CMCStatusInfoV2
id- -eme- -trustedAnchors id- -eme 26 PublishTrustAnchors
id- -eme- -authData id- -eme 27 AuthPublish
id- -eme- -batch equests id- -eme 28 BodyPartList
id- -eme- -batchResponses id- -eme 29 BodyPartList
id- -eme- -publishCert id- -eme 30 CMCPublicationlnfo
id- -eme- -modCertTemplate id- -eme 31 ModCertTemplate
id- -eme- -controlProcessed id- -eme 32 ControlsProcessed
id- -eme- -identityProofV2 id- -eme 34 IdentityProofV2
En ciertas puestas en práctica, no serán necesarios todos los controles. Por ejemplo, los controles relacionados con la protección de identidad no son usados en ciertas realizaciones ya que el módulo criptográfico está renovando un certificado existente. Una renovación es similar a otras solicitudes de certificación excepto en que la comprobación de la identidad es proporcionada por certificados existentes procedentes de una autoridad de certificación de confianza. Así, proporcionando los certificados necesarios para verificar la clave pública se consigue la comprobación de identidad del usuario final.
Otro ejemplo de controles que pueden no ser necesarios en ciertas puestas en práctica es el EncryptedPOP y DecryptedPOP, cuya función es proporcionar la Proof- of-Possession del par de claves del usuario final a la autoridad de certificación.
En realizaciones particulares, los controles usados por el módulo criptográfico están descritos a continuación. CMCStatusInfo devuelve información acerca del estado de una solicitud/respuesta de un cliente/servidor. En particular, el control de
Información de Estado de CMC Extendido proporciona:
CMCStatusInfoV2 ::= SEQUENCE {
cMCStatus CMCStatus,
bodyList SEQUENCE SIZE (1..MAX) OF BodyPartReference, statusString UTF8String OPTIONAL,
otherlnfo OtherStatusInfo OPTIONAL }
El campo CMCStatus contiene el valor de estado. Tiene varias opciones que representan el éxito o fracaso de una operación específica.
CMCStatus ::= INTEGE {
Success (éxito) (0),
- reserved (reservado) (1),
failed (fracaso) (2),
pending (pendiente) (3),
noSupport (4),
confirmRequired (5),
popRequired (6),
partial (parcial) (7)
}
El campo bodyList identifica los controles a los que se aplica el valor de estado. Si hay un error, el campo es la elección de bodyPartID de BodyPartReference con el valor 1. El campo satusString puede ser omitido en ciertas puestas en práctica, tal como cuando la información de descripción adicional que da no es necesaria. El campo otherlnfo contiene información adicional que expande la indicada en el código de estado de CMC devuelto. Su estructura es:
OtherStatusInfo : := CHOICE {
faillnfo CMCFailInfo,
pendlnfo Pendlnfo,
extendedFailInfo ExtendedFailInfo
}
Donde faillnfo proporciona un código de error que detalla el fracaso o fallo que ha ocurrido:
CMCFailInfo ::= INTEGER {
badAlg (0),
badMessageCheck (1),
badRequest (2), badTime (3),
badCertld (4),
unsupportedExt (5),
mustArchiveKeys (6),
badldentity (7),
pop equired (8),
popFailed (9),
noKeyReuse (10),
internalC AError (11),
tryLater (12),
authDataFail (13)
}
El campo pendlnfo es usado cuando el cMCStatus estaba o bien pendiente o bien era parcial. Contiene información acerca de cuándo y cómo el cliente debería solicitar el resultado de esta solicitud. extendedFailInfo es presentado cuando el cMCStatus ha fallado e incluye información acerca del error detallado.
TransactionID es un control de Identificador de transacción que identifica una transacción dada. Cada solicitud y respuesta que pertenecen a la misma transacción incluyen el mismo valor para este control.
TransactionID: := INTEGER
SenderNonce y RecipientNonce protegen frente ataques por repetición. Estos controles trabajan como sigue: En el primer mensaje de una transacción el Sender Nonce es incluido por el usuario final. La autoridad de certificación receptora refleja este valor de nuevo al emisor como un control de Recipient Nonce e incluye un nuevo valor como su control de Sender Nonce. A continuación, el usuario final compara el valor del Recipient Nonce recibido con su propio Sender Nonce y, si coinciden, es aceptado.
SenderNonce ::= OCTET STRTNG
RecipientNonce : := OCTET STRTNG ConfirmCertAcceptance es un control que gestiona la confirmación de los certificados emitidos por la autoridad de certificación y permite la etapa de confirmación del proceso.
Las autoridades de certificación requieren una confirmación positiva de que los certificados emitidos al usuario final son aceptables. La estructura de CMCCertID contiene el emisor y número de serie del certificado que es aceptado.
CMCCertld ::= IssuerAndSerialNumber
La etapa de confirmación es realizada como sigue: la autoridad de certificación selecciona como Información de Estado de CMC en una Respuesta de PKI la opción confirmRequired, entonces el cliente devuelve un control de Aceptación de Certificado de Confirmación en una Solicitud de PKI Completa. Finalmente la autoridad de certificación devuelve una Respuesta de PKI de nuevo con una Información de Estado de CMC extendida de éxito.
Opciones de Solicitud de Certificación. En este campo las solicitudes de certificación (CMRF) están incluidas. La estructura TaggedRequest es la siguiente:
TaggedRequest ::= CHOICE {
tcr [0] TaggedCertificationRequest,
crm [1] CertReqMsg,
orm [2] SEQUENCE {
bodyPartID BodyPartID,
requestMessageType OBJECT IDENTIFIER,
requestMessage Valué ANY DEFINED BY requestMessageType
}
}
Las diferentes elecciones de esta estructura incluye el tcr que se refiere al uso de sintaxis PKCS#10, cmr se refiere al uso de sintaxis de CRMF, y orm es una solicitud de certificación definida externamente. En realizaciones particulares, el módulo criptográfico usa la opción de crm cuando se usa el Formato de Mensaje de Solicitud de Certificación (CRMF).
La Sintaxis de Mensaje Criptográfico (CMS) soporta seis tipos de contenidos diferentes, pero el protocolo CMC considera cuatro de ellos: AuthenticatedData, Data, EnvelopedData, y SignedData. Entre estos tipos el módulo criptográfico usa el tipo SignedData. La sintaxis para la estructura de secuencia de CMS es:
TaggedContentlnfo ::= SEQUENCE {
bodyPartID BodyPartID,
contentlnfo Contentlnfo
}
bodyPartID es un entero que identifica este objeto de información de contenido y contentlnfo es el objeto de Contentlnfo correspondiente.
Contentlnfo encapsula un solo tipo de contenido identificado que es capaz de proporcionar un encapsulado adicional (SignedData). La estructura de Contentlnfo es: Contentlnfo : := SEQUENCE {
contentType ContentType,
content [0] EXPLICIT ANY DEFINED BY contentType }
ContentType ::= OBJECT IDENTIFIE
SignedData es usado para envolver los datos de PKI para asegurar su seguridad y es un sustituto para la Proof-of-Possession para la clave pública correspondiente. Esta PoP es llevada a cabo en cada solicitud, y está incluida en la estructura de CRMF. El tipo de contenido de datos firmados consiste de contenido de cualquier tipo y cero o más valores de firma. La estructura de SignedData ASN.l es:
SignedData ::= SEQUENCE {
versión CMSVersion,
digestAlgorithms DigestAlgorithmldentifiers,
encapContentlnfo EncapsulatedContentlnfo,
certificates [0] IMPLICIT CertificateSet OPTIONAL,
cris [1] FMPLICIT RevocationlnfoChoices OPTIONAL,
signerlnfos Signerlnfos }
DigestAlgorithmldentifiers: :=SET OF DigestAlgorithmldentifier
Signerlnfos ::= SET OF Signerlnfo
El significado de los campos SignedData incluye la versión que es el número de versión. Su cálculo depende de certificados, y campos de econtentType, y de Signerlnfo. El digestAlgorithm es el identificador del algoritmo de cifrado y encapContentInfo es el contenido firmado. Consiste de un EncapsulatedContentInfo cuya estructura es:
EncapsulatedContentInfo ::= SEQUENCE {
eContentType ContentType,
eContent [0] EXPLICIT OCTET STRTNG OPTIONAL }
donde eContentType es un identificador de objeto y eContent es el propio contenido.
Realizaciones del módulo criptográfico usarán este campo cuando no se usa firma externa.
certificates es la colección de certificados necesaria para certificar el trayecto desde una autoridad de certificación de raíz reconocedora al firmante en el campo signerlnfos.
En realizaciones particulares, cris es omitido, y signerlnfos es una colección de información por firmante almacenada en la estructura de Signerlnfo.
Signerlnfo ::= SEQUENCE {
versión CMSVersion,
sid Signerldentifier,
digestAlgorithm DigestAlgorithmldentifier,
signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL,
signatureAlgorithm SignatoeAlgorithmldentifier,
signature Signature Valué,
unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL } Signerldentifier : := CHOICE {
issuerAndSerialNumber IssuerAndSerialNumber,
subjectKeyldentifier [0] SubjectKeyldentifier }
SignedAttributes ::= SET SIZE (1..MAX) OF Attribute UnsignedAttributes ::= SET SIZE (1..MAX) OF Attribute
Attribute ::= SEQUENCE {
attrType OBJECT IDENTIFIE ,
attrValues SET OF AttributeValue }
Attribute Valué ::= ANY
SignatureValue ::= OCTET STRING
Los campos del Signerlnfo tienen el siguiente significado: versión es el número de versión de sintaxis y depende de la elección del Signerldentifier. En una puesta en práctica particular, su valor es 3 porque el módulo criptográfico usará la elección de subjectKeyldentifier de la estructura Signerldentifier. sid especifica el certificado del firmante y por ello la clave pública del firmante, que es necesaria por el receptor para verificar la firma. El signerldentifier proporciona dos opciones para especificar la clave pública, pero el módulo criptográfico usará típicamente la elección del subjectKeyldentifier para identificar el certificado del firmante por medio de un identificador de clave. digestAlgorithm identifica el algoritmo de cifrado del mensaje. Este cifrado del mensaje es calculado sobre el contenido junto con los atributos firmados.
signedattrs es una colección de atributos y es usado, por ejemplo, cuando el EncapsulatedContentlnfo no es id-data. Este campo contiene al menos dos atributos: content-type tiene el tipo de contenido del EncapsulatedContentlnfo y message-digest tiene el cifrado del mensaje del contenido.
signatureAlgorithm identifica el algoritmo de la firma, la firma es el resultado de la generación de la firma digital usando el cifrado del mensaje y la clave privada del firmante, y UnsignedAttrs son omitidos.
La estructura SignedData es usada para proporcionar autenticación e integridad a la solicitud de PKI firmando los Datos de PKI. Como se ha descrito antes, hay tres propósitos de alto nivel especificados para los cuales es usada una Proof-of- Possession: Signature, Key Encypherment y Key Agreement. Por ello, un certificado almacenado en el Dispositivo Hardware Criptográfico (HCD) será típicamente de uno de estos tres tipos. Así, hay tres opciones: si el par de claves tiene el propósito de firma asociado, la firma que envuelve los Datos de PKI puede ser generada directamente. De lo contrario, si el usuario final tiene cualquiera de los otros dos tipos de certificados, la firma no puede ser generada directamente. En esta situación, es llevado a cabo otro proceso para permitir generar una firma usando el material de la clave privada de una solicitud de certificación de firma embebida, es decir, incluida en el campo tcr o crm del Tagged equest.
OtherMsgSequence. En este campo, son llevados los objetos de datos arbitrarios que no están definidos en CMS. Su estructura y el significado de los campos son:
OtherMsg : := SEQUENCE {
bodyPartID BodyPartID,
otherMsgType OBJECT IDENTIFIER
otherMsgValue ANY DEFINED BY otherMsgType }
donde bodyPartID es el identificador para este objeto, otherMsgType es el Identificador de Objeto del tipo del cuerpo del mensaje, y otherMsgValue es la información.
La fig. 5 representa un ejemplo de intercambio 500 entre un usuario final y una autoridad de certificación (CA). En particular, la fig. 5 muestra los mensajes intercambiados entre el usuario final y la CA divididos en los tres estados: solicitud de Certificado, emisión de Certificado y Confirmación. En el proceso de certificación, el módulo criptográfico crea un mensaje CRMF, que incluye la información de solicitud del certificado y la Proof-of-Possession (PoP) de la clave privada usando mecanismos en bandas disponibles para CRMF.
La estructura de CRMF ASN.l es como sigue:
CertReqMessages ::= SEQUENCE SIZE (1..MAX) OF CerReqMsg
CertReqMsg ::= SEQUENCE {
certReq CertRequest,
popo ProofOfPossession OPTIONAL,
el contenido depende del tipo de clave
reglnfo SEQUENCE SIZE (1..MAX) of AttributeTypeAndValue OPTIONAL
} Ciertas realizaciones se refieren a un único nuevo proceso de solicitud de certificado. En estas realizaciones, CertReqMessages es una secuencia de un elemento de CertReqMsg. El campo reglnfo no se aplica en estas realizaciones ya que la información relacionada con el contexto de la solicitud de certificado es proporcionada en el campo certReq, y no es soportada comunicación con una Autoridad de Registro que podría incluir información adicional.
Lo siguiente describe la información de solicitud de certificado (campo certReq) y la información relacionada con la Proof-of-Possession (campo popo).
De acuerdo con el formato CRMF, la estructura CertReq consiste de los campos: CertRequest : := SEQUENCE {
certReqID INTEGER, - ID para hacer coincidir solicitud y respuesta
certTemplate CertTemplate, - Campos seleccionados del cert que han de ser emitidos controls Controls OPTIONAL } — Atributos que afectan a la emisión cuando el campo de controles no se aplica, certReqID es rellenado por el módulo criptográfico con los Identificadores de parte de Cuerpo codificados, y certTemplate es la estructura que define toda la información que puede ser incluida en la solicitud de certificado:
CertTemplate ::= SEQUENCE {
Versión [0]Version OPTIONAL,
SerialNumber [ 1 ] INTEGER OPTIONAL,
signingAlg [2] Algorithmldentifier OPTIONAL,
issuer [3] Ñame OPTIONAL,
validity [4] OptionalValidity OPTIONAL,
subject [5] Ñame OPTIONAL,
publicKey [6] SubjectPublicKeylnfo OPTIONAL,
issuerUID [7] Uniqueldentifier OPTIONAL,
subjectUID [8] Uniqueldentifier OPTIONAL,
extensions [9] Extensions OPTIONAL}
OptionalValidity ::= SEQUENCE {
notBefore [0] Time OPTIONAL, notAfter [1] Time OPTIONAL } -al menos uno debe estar presente
Time ::= CHOICE {
utcTime UTCTime,
generalTime GeneralizedTime }
donde versión es llenado por el módulo criptográfico con valor 2, serialnumber es asignado por la CA, signingAlg es asignado por la CA, issuer es asignado por la CA, validity puede ser asignado por el módulo criptográfico, en las siguientes situaciones:
Si el Certificado que ha de ser emitido va a ser un certificado digital de un solo uso, entonces el periodo de validez debe ser menor de 1 hora, con notBefore igual a CurrentTime + 1 minuto y NotAfter igual a CurrentTime + 1 hora.
Si el certificado que ha de ser emitido se supone que ha de ser almacenado en caché por la aplicación para otro uso, entonces la aplicación puede proporcionar un periodo de validez. De lo contrario, este campo debe dejarse vacío.
Si el certificado que ha de ser emitido va a ser incluido en el HCD, entonces el usuario final es preguntado sobre el periodo de validez para el cual quieren solicitar el certificado.
El campo subject es completado por el módulo criptográfico con el subject Distinguised Ñame (DN) del certificado almacenado en el HCD y extraído por el módulo criptográfico. El campo publicKey es completa por el módulo criptográfico con la clave pública incluida en el certificado almacenado en el HCD y extraído por el módulo criptográfico. En esta puesta en práctica, issuerUID y subjectUID son omitidos, extensions es rellenado por el módulo criptográfico con nuevos usos/campos de clave necesaria y con la extensión de Subject Key Identifier si es necesario. Esta última extensión es necesaria para firmar los Datos de PKI si el usuario final no tiene un certificado digital para el propósito de firma.
Extensions ::= SEQUENCE SIZE (1..MAX) OF Extensión
Extensión ::= SEQUENCE {
extnID OBJECT IDENTIFIER,
critical BOOLEAN DEFAULT FALSE,
extn Valué OCTET STPJNG
- contiene la codificación DER de un valor ASN.l correspondiente al tipo de extensión identificado por extnID
}
El módulo criptográfico añadirá, como una extensión en la estructura CertTemplate, el keyUsage/field necesario para la operación que se está llevando a cabo y si es necesaria la extensión de Subject Key Identifier (cuando el par de claves no tiene un certificado digital para el propósito de firma).
La estructura de datos KeyUsage es:
Id-ce-keyUsage OBJECT IDENTIFIER ::= { 2 5 29 15 }
KeyUsage ::= BIT STRING {
digitalSignature (0),
nonrepudiation (1), (en ciertas realizaciones, puede ser renombrado este bit a contentCommitment)
keyEncipherment (2),
dataEncipherment (3),
keyAgreement (4),
keyCertSign (5),
cRLSign (6),
encipherOnly (7),
decipherOnly (8),
Así, la estructura de Extensión tendrá los siguientes valores:
extnID igual a identificador de objeto de id-ce-keyUsage.
Critical marcado como CRITICAL.
extnValue corresponde a la estructura codificada de ASN.l DER de la estructura KeyUsage anterior.
El valor keyUsage será seleccionado dependiendo de las necesidades de la Aplicación
210 (véase fig.2), La extensión del Subject Key Identifier proporciona un mecanismo para identificar certificados que contienen una clave pública particular:
SubjectKeyldentifier ::= Keyldentifier
Keyldentifier ::= OCTET STRING
Con la excepción del campo PublicKey, la CA está autorizada para modificar cualquier campo solicitado. El certificado devuelto necesita ser comprobado por el solicitante para ver si los campos han sido configurados de una manera aceptable. Sin embargo, la CA usa típicamente los campos plantilla si es posible.
La Proof-of-Possession (PoP) depende del propósito para el que el certificado está siendo solicitado. Los propósitos de nivel alto especificados cubren el cifrado, la firma digital y/o el acuerdo de clave. La solicitud hecha por el usuario final podría tener más de un propósito. En los casos para los que la clave pública es una clave multipropósito, se aplican las siguientes prioridades:
Si la pública solicitada contiene un propósito de cifrado, entonces es usado el método de cifrado descrito más abajo. El método de cifrado seleccionado debería ser soportado por la CA. De lo contrario, y si la clave pública solicitada contiene un propósito de firma digital, entonces el usuario final sigue el método de firma descrito a continuación. Finalmente, si ninguno de los dos propósitos anteriores es solicitado, y la clave pública es para propósitos de acuerdo de clave, se usa el método de acuerdo de clave.
Lo siguiente proporciona información con respecto a métodos disponibles de PoP. La estructura de datos para el PoP en tal estándar es como sigue:
Proof-of-Possession ::= CHOICE {
raVerified [0] NULL,
signature [1] POPOSigningKey,
KeyEncipherment [2] POPOPrivKey,
KeyAgreement [3] POPOPrivKey }
Si la clave pública solicitada es para cifrado, la CA tiene tres métodos diferentes: La clave privada puede ser proporcionada a la CA, un desafío cifrado desde la CA puede ser descifrado (método directo), o el certificado creado puede ser devuelto cifrado y usado como la respuesta del desafío (método indirecto)
Hay una restricción debido al protocolo CMC en el uso del método PoP: El protocolo no soporta la provisión de la clave privada ni el método indirecto . Por ello se usa el método directo. La estructura general ASN.l para las claves key encipherment es:
POPOPrivKey ::= CHOICE {
This Message [0] BIT STRING, -deprecated
subsequentMessage [1] SubsequentMessage, dhMAC [2] BIT STPJNG, - deprecated
agreeMAC [3] PKMACValue,
encryptedKey [4]EnvelopedData}
Para Acuerdo de clave (solamente), la posesión es probada en este mensaje (que contiene una MAC (sobre el valor DER codificado del parámetro certReq en CertReqMsg, que debe incluir tanto el sujeto como publicKey) basado en una clave derivada de la clave privada DH de la entidad final y la clave pública DH de la CA);
El valor dhMAC debe ser calculado en base a RFC 2875 para Proof-of-Possession de DH estática.
SubsequentMessage ::= INTEGER {
encrCert (0),
challengeResp (1) }
En puestas en práctica particulares, el campo SubsequentMessage es challengeResp ya que los otros métodos no están soportados.
Usando el método directo, el valor del SubsequentMessage es challengeResponse, que indica que la CA envía un desafío al usuario final y necesitan descifrarlo y generar una respuesta correcta. A continuación, si la respuesta es correcta, la CA emitirá y enviará el nuevo certificado digital al usuario final.
Si la clave pública que ha de ser certificada incluye propósitos de firmado, la estructura elegida en la estructura de Proof-of-Possession anterior debe ser la siguiente:
POPOSigningKey ::= SEQUENCE {
poposklnput [0] POPOSigningKeylnput OPTIONAL,
algorithmldentifier [0] Algorithmldentifier,
signature BIT STPJNG }
POPOSigningKeylnput ::= SEQUENCE {
authlnfo CHOICE{
sender [OJGeneralName
- usado solamente si una identidad autentificada ha sido establecida para el emisor (por ejemplo, un DN de un certificado previamente emitido y actualmente válido)
publicKeyMAC PKMACValue },
- usado si GeneralName no existe actualmente autentificado para el emisor; publicKeyMAC contiene una MAC basada en una contraseña sobre el valor
DE codificado de PublicKey
publicKey SubjectPublicKeylnfo }— desde CertTemplate
Hay tres casos que necesitan ser evaluados cuando se está haciendo una POP para una clave de firma. En una realización, el módulo criptográfico está asociado con el tercer caso, es decir, "el sujeto del certificado pone su nombre en la estructura de Plantilla del Certificado junto con la clave pública. En estos casos el poposklnput es omitido desde la estructura POPOSigningKey. El campo signature es calculado sobre la estructura de la plantilla del certificado DER codificado."
La clave pública usada por la CA actual para verificar la Proof-of-Possession está ya certificada en un certificado emitido por una CA que pertenece a otra PKI (denominada, por ejemplo, PKI l). Se supone una relación de confianza entre la PKI l y la PKI a la que pertenece la CA actual (PKI 2). Por ello, el mecanismo de registro/certificación se aplica como si el usuario tuviera un contacto previo con la CA de la PKI 2. Además, el módulo criptográfico verifica la firma del certificado emitido por la CA (etapa de confirmación). Se supone que el certificado de la CA correspondiente es conocido y puede ser usado por el módulo criptográfico.
Si la clave pública solicitada es para acuerdo de clave, ambos lados establecerán una clave secreta compartida. Los métodos para cumplir esta tarea son el método directo, ya explicado antes, y compartir un secreto con la CA y usar su valor para generar una información de MAC. El campo del POPPrivKey usado para el acuerdo de clave es agreeMAC que contiene el valor de MAC calculado por el secreto compartido.
Varias entidades participan durante el proceso de solicitar un nuevo certificado, cada una de las cuales realiza una tarea diferente. Por ello, hay algunas cuestiones que deben garantizarse no solamente para asegurar las identidades de los usuarios sino también para proporcionar la certeza de que son respetadas todas las políticas definidas en cada entidad. La función principal de la Declaración de Práctica de Certificación (CPS) es declarar las prácticas y mecanismos que emplea una CA en todas las tareas relacionadas con la emisión, gestión, revocación y renovación/cambio de clave de los certificados. Se encarga también de la relación entre todas las entidades que participan en una PKI, tal como el abonado, la CA, la RA, la parte que confía y cualquier otro participante o autoridad. Como la CPS puede contener detalles sensibles de su sistema, normalmente se publica un resumen de éste.
Una limitación del CPS es que no constituye un contrato ni ata a los participantes de PKI. Por ello, en la mayoría de los casos es necesario incluir un documento separado que incorpora parte de las referencias CPS para crear una relación contractual entre las partes.
Hay otro concepto importante para definir la política y la relación en una PKI. Es la Política de Certificado (CP). La CP es un conjunto de reglas, requisitos y estándares impuestos por la PKI con respecto a los distintos temas. En resumen, la CP establece qué participantes deben hacer qué y se aplica a múltiples CA, organizaciones y dominios. Adicionalmente, el CPS declara cómo una CA y otros participantes se comportan en un cierto dominio, es decir, es aplicado a una única CA, poniendo en práctica todos los procedimientos para satisfacer los requisitos de CP.
En ciertas situaciones, la CA que recibe la solicitud para la nueva información de KeyUsage/field no es la misma o no está incluida en la misma PKI que la CA que certificó previamente el par de claves criptográficas. En este caso, el usuario final necesita conocimiento del CPS de ambas PKI para mantener el nivel de seguridad y realizar los aspectos necesarios que sus protocolos correspondientes necesitan.
La CP debería identificar un conjunto de aplicaciones o usos para certificar y establecer el nivel de seguridad para ellos. A continuación, puede presentar los requisitos de PKI apropiados para esas aplicaciones/usuarios. La PKI soporta servicios de seguridad para proporcionar Identificación, Autentificación, e Integridad a través de los procesos de Proof-of-Possession, tales como firmas digitales e intercambios de clave. Los niveles de seguridad definen el comportamiento de las CA con respecto a la identificación de los receptores de certificado, y la emisión, gestión y revocación de tales certificados. Un CPS indica cómo una CA establece la seguridad. Una CA puede poner en práctica la CP a distintos niveles de seguridad. La elección del nivel de seguridad dependerá del proceso de Proof-of-Possession que se está usando cada vez que es solicitada la firma, cifrado o acuerdo de clave.
El periodo de validez del certificado del nuevo certificado digital dependerá de los niveles de PKI de seguridad elegidos para la aplicación y en el KeyUsage/field requerido. Por ejemplo, la seguridad y el periodo de validez para la firma digital no deberían ser los mismos que para el cifrado de la clave o acuerdo de clave. El desafío con el periodo de validez del certificado es la emisión del certificado digital de un solo uso (OTDC). Cuando se requiere un OTDC, el periodo de validez no debería ser el mismo que el de un certificado digital normal. El problema está en el hecho de que el OTDC tiene un periodo de uso limitado, debido a su propia definición: Cuando el HCD es desconectado, el OTDC se "perderá" junto con todos los otros datos almacenados en la memoria caché del software. Por ello, el periodo de validez OTDC no necesita ser más alto que el tiempo de disponibilidad, es decir, el tiempo durante el cual es almacenado en la memoria caché del software. De lo contrario la CA emitirá y gestionará muchos certificados digitales cuando solamente el último o incluso ninguno de ellos es necesario.
El módulo criptográfico asignará al CRMF el mismo periodo de validez que el periodo que tenía el certificado digital extraído. Adicionalmente, si es necesario (tal como con el OTDC) el módulo criptográfico permitirá asignar un periodo de validez diferente al nuevo certificado digital.
Proporcionar credenciales de la identidad del usuario no es un proceso aislado que haya de ser realizado en un único momento del proceso completo de gestión de certificado. Es necesario asegurar la identidad del usuario durante el proceso completo a todas las entidades de la PKI. Hay varios métodos en los que esta identidad es asegurada y verificada:
Si el usuario final tiene una clave privada que ha sido previamente certificada con un certificado digital por una CA que pertenece a una PKI (PKI l), la validez de este certificado digital, cuando se solicita la nueva información KeyUsage/field, es verificada independientemente de si la nueva CA es la misma o está incluida en otra PKI (PKI 2). Esta verificación proporciona una Proof-of-Identity del usuario.
La Proof-of-Possession es el método a través del cual el usuario proporciona una garantía de su identidad. Dependiendo de qué información keyUsange/field es requerida, el método Proof-of-Possession difiere, pero el resultado es que el usuario demuestra su identidad ante la CA. En realizaciones particulares, la Proof-of-Identity es hecha usando métodos en línea (on-line).
El Dispositivo Hardware Criptográfico (HCS) 216 es el soporte físico en que el par de claves es embebido y que contiene el certificado digital con los diferentes KeyUsages de la clave pública correspondiente. Un ejemplo de HCD es una tarjeta electrónica, que es cualquier tarjeta con circuitos integrados embebidos que puede procesar datos y programas lógicos. Hay distintas categorías de tarjetas electrónicas:
- Tarjetas de memoria, que contienen solamente componentes de almacenamiento de memoria no volátil y algunas veces alguna lógica de seguridad específica. - Tarjetas de microprocesador, que contiene componentes de microprocesador además de componentes de memoria. El microprocesador permite que la tarjeta realice diferentes funciones y use diferentes aplicaciones.
- Tarjetas criptográficas son tarjetas de microprocesador avanzadas equipadas con hardware criptográfico especializado que puede realizar operaciones criptográficas.
La mayoría de las tarjetas criptográficas están equipadas con hardware criptográfico especializado que permite el uso de algoritmos tales como RSA y DSA. Estas tarjetas son también capaces de generar pares de claves sobre la tarjeta, evitando por ello el riesgo que tiene la existencia de más de una copia de la clave. El uso principal de la tarjeta electrónica es para firma digital y propósitos de identificación segura.
Otra realización es usada para identificar a su propietario sin lugar a dudas en un ámbito electrónico. Esta identificación es hecha proporcionando la propia Tarjeta de Identidad digital (Id-Card) con herramientas criptográficas y certificados que hacen posible realizar varios procesos criptográficos, tales como la firma digital.
Una realización específica se refiera a la Id-Card española (DNI electrónico (e- DNI)) que proporciona las siguientes características:
- Tratar con la administración pública con el fin de llevar a cabo todas sus funciones (Administración informática).
- Hacer transacciones seguras entre bancos.
- Usar un ordenador personal de un modo seguro mediante identificación personal.
- Llevar a cabo cualquier tipo de aplicación a través de Internet con la certeza de la identidad del usuario, como transacciones de comercio electrónico.
El e-DNI tiene una EEPROM con 34 Kbytes de capacidad. La información en el chip está distribuida en tres zonas diferentes con permisos de acceso diferentes. Tiene una zona pública, una zona privada y una zona segura. Los permisos del usuario para cada zona son diferentes.
El invento puede también incluir un número de funciones que han de ser realizadas por un procesador de ordenador, tal como un microprocesador. El microprocesador puede ser un microprocesador especializado o dedicado que está configurado para realizar tareas particulares de acuerdo con el invento, ejecutando un código de software legible por la máquina que define las tareas particulares realizadas por el invento. El microprocesador también puede estar configurado para funcionar y comunicar con otros dispositivos tales como módulos de acceso de memoria directa, dispositivos de almacenamiento de memoria, hardware relacionado con Internet, y otros dispositivos que se refieren a la transmisión de datos de acuerdo con el invento. El código de software puede ser configurado usando formatos de software y lenguajes de programación tales como Java, C++, XML (Lenguaje de Marcación Extensible) y otros lenguajes que pueden ser usados para definir funciones que se refieren a operaciones de dispositivos requeridos para llevar a la práctica las operaciones funcionales relacionadas con el invento. El código puede ser escrito en diferentes formas y estilos, muchos de los cuales son conocidos por los expertos en la técnica. Diferentes formatos de código, configuraciones de código, estilos y formas de programas de software y otros medios de código de configuración para definir las operaciones de un microprocesador de acuerdo con el invento no se saldrán fuera del espíritu y marco del invento.
Dentro de los diferentes tipos de dispositivos, tales como ordenadores portátiles o de sobremesa, dispositivos de mano con procesadores o lógica de tratamiento, y también posiblemente servidores u otros dispositivos que utilizan el invento, existen diferentes tipos de dispositivos de memoria para almacenar y recuperar información mientras realizan funciones de acuerdo con el invento. Los dispositivos de memoria caché están a menudo incluidos en tales ordenadores para su uso por la unidad de tratamiento central como una posición de almacenamiento de información que es frecuentemente almacenada y recuperada. Similarmente, una memoria persistente es también usada frecuentemente por tales ordenadores para mantener información que es frecuentemente recuperada por la unidad de tratamiento central, pero que no son a menudo alterados dentro de la memoria persistente, a diferencia de la memoria caché.
La memoria principal es también usualmente incluida para almacenar y recuperar mayores cantidades de información tales como datos y aplicaciones de software configurados para realizar funciones de acuerdo con el invento cuando son ejecutadas por la unidad de tratamiento central. Estos dispositivos de memoria pueden ser configurados como memoria de acceso aleatorio (RAM), memoria de acceso aleatorio estática (SRAM), memoria de acceso aleatorio dinámica (DRAM), memoria flash, y otros dispositivos de almacenamiento de memoria a los que se puede acceder por una unidad de tratamiento central para almacenar y recuperar información. Durante las operaciones de almacenamiento y recuperación de datos, estos dispositivos de memoria son transformados para tener estados diferentes, tales como cargas eléctricas diferentes, polaridad magnética diferente, y similares. Así, los sistemas y métodos configurados de acuerdo con el invento como se ha descrito aquí permiten la transformación física de estos dispositivos de memoria. Por consiguiente, el invento como se ha descrito aquí esta dirigido a sistemas y métodos nuevos y útiles que, en una o más realizaciones, son capaces de transformar el dispositivo de memoria a un estado diferente. El invento no está limitado a ningún tipo particular de dispositivo de memoria, o a ningún protocolo usado normalmente para almacenar y recuperar información a estos dispositivos de memoria y desde ellos, respectivamente.
Las realizaciones del sistema y método descritas aquí facilitan el uso de claves criptográficas. Adicionalmente, algunas realizaciones pueden ser usadas junto con uno o más dispositivos tradicionales, tales como dispositivos informáticos. Por ejemplo, una realización puede ser usada como una mejora de dispositivos informáticos y/o dispositivos de comunicación existentes.
Aunque los componentes y módulos ilustrados aquí están mostrados y descritos en una disposición particular, la disposición de componentes y módulos puede ser alterada para utilizar claves criptográficas de un modo diferente. En otras realizaciones, uno o más componentes o módulos adicionales pueden ser añadidos a los sistemas descritos, y uno o más componentes o módulos pueden ser retirados de los sistemas descritos. Realizaciones alternativas pueden combinar dos o más de los componentes o módulos descritos en un solo componente o módulo.
Aunque se han descrito e ilustrado realizaciones específicas del invento, el invento no ha de estar limitado a las formas o disposiciones específicas de partes así descritas e ilustradas. El marco del invento ha de ser definido por las reivindicaciones adjuntas y sus equivalentes.

Claims

RFTVTN CACTONFS
Ia.- Un método que comprende: leer un certificado digital existente desde un dispositivo hardware criptográfico, el cual almacena un par de claves criptográficas existente y un certificado digital que incluye la parte pública de la clave o clave pública; extraer la clave pública del certificado digital existente; generar un mensaje de solicitud de certificado que identifique un nuevo uso asociado con la clave pública; firmar el mensaje de solicitud de certificado; comunicar el mensaje de solicitud de certificado a una autoridad de certificación; recibir un nuevo certificado digital de la autoridad de certificación, en el que el nuevo certificado digital incluye el nuevo uso; y aplicar el nuevo certificado digital a una operación criptográfica usando el par de claves existentes.
2a.- El método según la reivindicación Ia, en el que el dispositivo hardware criptográfico es incapaz de almacenar datos adicionales.
3a- El método según la reivindicación Ia, en el que el dispositivo hardware criptográfico es una tarjeta electrónica.
4a- El método según la reivindicación Ia, en el que la operación criptográfica es una operación de firma digital.
5a- El método según la reivindicación Ia, en el que la operación criptográfica es una operación de cifrado.
6a.- El método según la reivindicación Ia, en el que el dispositivo hardware criptográfico es un token de Bus en Serie Universal (token USB).
7a.- El método según la reivindicación Ia, en el que generar un mensaje de solicitud de certificado que identifique un nuevo uso asociado con la clave pública incluye generar el mensaje de solicitud de certificado usando un formato de mensaje de solicitud de certificado.
8a.- El método según la reivindicación Ia, que comprende además solicitar una contraseña al usuario asociado con el dispositivo hardware criptográfico antes de extraer la clave pública del certificado digital.
9a.- El método según la reivindicación Ia, que comprende además solicitar un número de identificación personal (PIN) al usuario asociado con el dispositivo hardware criptográfico antes de extraer la clave pública del certificado digital.
10a.- El método según la reivindicación Ia, en el que el uso de una nueva clave pública no está soportado por el certificado digital existente. 1 Ia.- El método según la reivindicación Ia, en el que el uso de una nueva clave pública no está incluido en el certificado digital existente.
12a.- El método según la reivindicación Ia, que comprende además almacenar el nuevo certificado digital en el dispositivo hardware criptográfico.
13a.- El método según la reivindicación Ia, que comprende además borrar el nuevo certificado digital a la terminación de la operación criptográfica.
14a.- Un método que comprende: leer un certificado digital existente desde un dispositivo hardware criptográfico, el cual almacena un par de claves criptográficas existente y un certificado digital que incluye la parte pública de la clave o clave pública; extraer la clave pública del certificado digital existente; generar un mensaje de solicitud de certificado que identifique un nuevo campo asociado con la clave pública; firmar el mensaje de solicitud de certificado; comunicar el mensaje de solicitud de certificado a una autoridad de certificación; recibir un nuevo certificado digital de la autoridad de certificación, en el que el nuevo certificado digital incluye el nuevo campo; y aplicar el nuevo certificado digital a una operación criptográfica usando el par de claves existente.
15a.- El método según la reivindicación 14a, en el que el dispositivo hardware criptográfico es incapaz de almacenar datos adicionales.
16a- El método según la reivindicación 14a, en el que la operación criptográfica es una operación de firma digital.
17a- El método según la reivindicación 14a, en el que la operación criptográfica es una operación de cifrado.
18a.- El método según la reivindicación 14a, que comprende además solicitar una contraseña al usuario asociado con el dispositivo hardware criptográfico antes de extraer la clave pública del certificado digital.
19a.- El método según la reivindicación 14a, que comprende además solicitar un número de identificación personal (PIN) al usuario asociado con el dispositivo hardware criptográfico antes de extraer la clave pública del certificado digital.
20a.- El método según la reivindicación 14a, en el que el nuevo campo no está soportado por el certificado digital existente.
21a.- El método según la reivindicación 14a, en el que el nuevo campo no está contenido en el certificado digital existente.
22a.- El método según la reivindicación 14a, que comprende además borrar el nuevo certificado digital a la terminación de la operación criptográfica. 23a.- Un método que comprende: generar una solicitud para un nuevo certificado digital que identifique un nuevo uso, en el que el nuevo uso no está soportado por un certificado digital existente; comunicar la solicitud a una autoridad de certificación; recibir el nuevo certificado digital de la autoridad de certificación, en el que el nuevo certificado digital incluye el nuevo uso; realizar una operación criptográfica usando el nuevo certificado digital y el par de claves existentes durante una sesión en curso; y borrar el nuevo certificado digital al final de la sesión en curso.
24a.- El método según la reivindicación 23a, en el que generar una solicitud para un nuevo certificado digital que identifique un nuevo uso incluye leer el certificado digital existente desde un dispositivo hardware criptográfico.
25a.- El método según la reivindicación 23a, en el que generar una solicitud para un nuevo certificado digital que identifique un nuevo uso incluye extraer una clave pública desde el certificado digital existente.
26a.- El método según la reivindicación 23a, que comprende además almacenar el nuevo certificado digital en un dispositivo de memoria volátil durante la sesión en curso.
27a.- El método según la reivindicación 23a, que comprende además almacenar el nuevo certificado digital en un dispositivo hardware criptográfico durante la sesión en curso.
28a.- El método según la reivindicación 23a, en el que el final de la sesión en curso ocurre cuando un dispositivo hardware criptográfico que almacena el certificado digital existente es desconectado.
29a.- Un método que comprende: generar una solicitud para un nuevo certificado digital que identifique un nuevo campo asociado con el certificado digital, en el que el nuevo campo no está incluido en un certificado digital existente; comunicar la solicitud a una autoridad de certificación; recibir el nuevo certificado digital de la autoridad de certificación, en el que el nuevo certificado digital incluye el nuevo campo; realizar una operación criptográfica usando el nuevo certificado digital y el par de claves existentes durante una sesión en curso; y borrar el nuevo certificado digital al final de la sesión en curso.
30a.- El método según la reivindicación 29a, en el que generar una solicitud para un nuevo certificado digital que identifique un nuevo campo incluye leer el certificado digital existente desde un dispositivo hardware criptográfico.
31a.- El método según la reivindicación 29a, en el que generar una solicitud para un nuevo certificado digital que identifique un nuevo campo incluye extraer una clave pública desde el certificado digital existente.
32a.- El método según la reivindicación 29a, que comprende además almacenar el nuevo certificado digital en un dispositivo de memoria volátil durante la sesión en curso.
33a.- El método según la reivindicación 29a, que comprende además almacenar el nuevo certificado digital en un dispositivo hardware criptográfico durante la sesión en curso.
34a.- El método según la reivindicación 29a, en el que el final de la sesión en curso ocurre cuando un dispositivo hardware criptográfico que almacena el certificado digital existente es desconectado.
35a.- Un aparato que comprende: una unidad de hardware criptográfico configurado para comunicar con un dispositivo hardware criptográfico acoplado al aparato; y un módulo criptográfico acoplado a la unidad de hardware criptográfico y configurado para generar una solicitud para un nuevo certificado digital que identifique un nuevo uso o un nuevo campo que no está soportado por un certificado digital existente, el módulo criptográfico además para recibir un nuevo certificado digital que incluye el nuevo uso o campo de una autoridad de certificación y para realizar una operación criptográfica usando el nuevo certificado digital y una clave pública almacenada en el dispositivo hardware criptográfico, en el que el módulo criptográfico está además configurado para borrar el nuevo certificado digital a la terminación de la sesión en curso.
36a.- El aparato según la reivindicación 35a, en el que la terminación de la sesión en curso ocurre cuando el dispositivo hardware criptográfico es desacoplado del aparato.
37a.- El aparato según la reivindicación 35a, en el que el módulo criptográfico está configurado para intercambiar datos con el dispositivo hardware criptográfico a través de la unidad de hardware criptográfico.
38a.- El aparato según la reivindicación 35a, que comprende además un módulo de comunicación acoplado al módulo criptográfico y configurado para comunicar con la autoridad de certificación y una autoridad de registro.
39a.- El aparato según la reivindicación 35a, que comprende además un dispositivo de almacenamiento acoplado al módulo criptográfico y configurado para almacenar el nuevo certificado digital durante la sesión en curso.
PCT/ES2010/070527 2010-07-29 2010-07-29 Ststemas y metodos para usar claves criptografiicas WO2012013833A1 (es)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/ES2010/070527 WO2012013833A1 (es) 2010-07-29 2010-07-29 Ststemas y metodos para usar claves criptografiicas

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/ES2010/070527 WO2012013833A1 (es) 2010-07-29 2010-07-29 Ststemas y metodos para usar claves criptografiicas

Publications (1)

Publication Number Publication Date
WO2012013833A1 true WO2012013833A1 (es) 2012-02-02

Family

ID=45529449

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/ES2010/070527 WO2012013833A1 (es) 2010-07-29 2010-07-29 Ststemas y metodos para usar claves criptografiicas

Country Status (1)

Country Link
WO (1) WO2012013833A1 (es)

Non-Patent Citations (4)

* Cited by examiner, † Cited by third party
Title
"Internet X.509 Public Key Infrastructure Certificateand Certificate Revocation List (CRL) Profile", IETF, May 2008 (2008-05-01), Retrieved from the Internet <URL:http://www.ietf.org/rfc/rfc5280.txt> *
"New ASN.l Modules for the Public Key Infrastructure Using X.509 (PKIX)", IETF, June 2010 (2010-06-01), pages 54., Retrieved from the Internet <URL:http://www.ietf.org/rfc/rfc5912.txt> *
C ADAMS ET AL.: "Internet X.509 Public Key Infrastructure Certificate Management Protocol (CMP), RFC 4210", IETF, September 2005 (2005-09-01), Retrieved from the Internet <URL:http://www.ietf.org/rfc/rfc4210.txt> *
C ADAMS ET AL.: "Internet X.509 Public Key Infrastructure. Certificate Management Protocol (CMP) draft-ietf-pkix-rfc2510bis-09.txt", IETF, February 2001 (2001-02-01), Retrieved from the Internet <URL:ahref=''http://tools.ietf.org/html/draft-ietf-pkix-rfc2510bis-03''>http://tools.ietf.org/html/draft-ietf-pkix-rfc2510bis-03</a> *

Similar Documents

Publication Publication Date Title
US20100268942A1 (en) Systems and Methods for Using Cryptographic Keys
US8578467B2 (en) System and methods for online authentication
JP5680115B2 (ja) データ・セキュリティ装置のためのトランザクション監査
JP4490477B2 (ja) トークン提供
US9397839B2 (en) Non-hierarchical infrastructure for managing twin-security keys of physical persons or of elements (IGCP/PKI)
US8505075B2 (en) Enterprise device recovery
ES2904501T3 (es) Implementación de un almacenamiento seguro con protección de integridad
US8756674B2 (en) System and methods for online authentication
CN105144626B (zh) 提供安全性的方法和设备
ES2634024B1 (es) Método seguro para compartir datos y controlar el acceso a los mismos en la nube
ES2665887T3 (es) Sistema de datos seguro
WO2009103824A1 (es) Transferencia segura de datos
JPH113033A (ja) クライアント−サーバ電子取引においてクライアントの本人確認を確立する方法、それに関連するスマートカードとサーバ、および、ユーザが検証者と共に操作を行うことが認可されるかどうかを決定する方法とシステム
ES2659580T3 (es) Procedimiento de comprobación de la preservación de privacidad entre tres partes que se comunican entre sí
GB2385955A (en) Key certification using certificate chains
KR100939725B1 (ko) 모바일 단말기 인증 방법
KR100947119B1 (ko) 인증서 검증 방법, 인증서 관리 방법 및 이를 수행하는단말
ES2773705T3 (es) Método para proporcionar firmas digitales seguras
CN110493177A (zh) 基于非对称密钥池对和序列号的量子通信服务站aka密钥协商方法和系统
CN108418692B (zh) 认证证书的在线写入方法
ES2923919T3 (es) Protección de una comunicación P2P
Yoon et al. Security enhancement scheme for mobile device using H/W cryptographic module
JP4052158B2 (ja) Ｉｃカードシステムおよびｉｃカード発行方法
WO2012013833A1 (es) Ststemas y metodos para usar claves criptografiicas
Lu et al. Communication security between a computer and a hardware token

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 10855241

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 10855241

Country of ref document: EP

Kind code of ref document: A1