DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This action is responsive to communication received on 12/05/2025. Claims 1-20 are pending of which claims 1,14 and 20 are amended
The Examiner recommends filing a written authorization for Internet communication in response to the present action. Doing so permits the USPTO to communicate with Applicant using Internet email to schedule interviews or discuss other aspects of the application. Without a written authorization in place, the USPTO cannot respond to Internet correspondence received from Applicant. The preferred method of providing authorization is by filing form PTO/SB/439, available at: https://www.uspto.gov/patent/forms/forms. See MPEP § 502.03 for other methods of providing written authorization.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-4, 8-17 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Mathias US 2020/0052905, and further in view of Vass US 2020/0204527.
Regarding claims 1,14 and 20, Matthias teaches a method, a computer program product comprising executable code and an apparatus comprising: a processor; and a memory that stores code executable by the processor to: receive, at the apparatus during a secure pairing process with a second computing device, a first key associated with the second computing device(first device/mobile device and second device/system initiate pairing process and exchange public keys, ¶36).
[0036] In various embodiments, the mobile device initially performs a pairing procedure with the system. This procedure may include the mobile device exchanging short-lived public key pairs with the system and a processor of the mobile device generating a shared secret with the system based on the exchanged keys (e.g., using elliptic curve Diffie-Hellman (ECDH)). A secure circuit of the mobile device may also generate a public key pair to allow the system to authenticate the mobile device. The secure circuit may be a secure element, for example. As used herein, the term “secure element” is to be interpreted according to its understood meaning in the art, which includes circuitry (e.g., often a single-chip microcontroller) that is configured to store information in a tamper-resistant manner that resists unauthorized extraction of that information. Non-limiting examples of form factors for secure elements include UICC, embedded SE, and microSD. In some embodiments, the secure element is also used for other types of transactions such as payment transactions, for example. For payment transactions, the secure element may cryptographically store data for payment instruments (e.g., credit cards) and owners (e.g., cardholders), entry to physical locations or buildings, transmit access, etc. In some embodiments, at least a portion of secure element functionality may be cloud-based. In these embodiments, the secure element on a device may store virtual information which may be used to retrieve actual required information that is stored on a server. In some embodiments, other types of secure circuits or secure processors may perform functionality described as being performed by a secure element, including, for example, a secure enclave processor discussed below.
generate a digital certificate based on a key pair associated with the apparatus, the key pair dynamically generated in response to initiation of the secure pairing process(a certificate is create for authentication of the system, ¶37)
[0037] After the key exchange, the mobile device may then encrypt a certificate for the key pair using the private key and send the encrypted certificate to the system. The mobile device may then display a value derived based on the public key pair and ask the user of the mobile device to confirm that the value is also displayed on a display of the system, which may derive the value based on the public key in the certificate.
calculate a digital fingerprint for the apparatus based on the first key associated with the second computing device and at least one of the keys of the key pair associated with the apparatus(a digital signature is created by signing a verifiable cryptographic signature i.e fingerprint, ¶42)
[0042] As used herein, the term “secure channel” refers to either a dedicated path for communicating data (i.e., a path shared by only the intended participants) or communicating encrypted data or signed data using cryptographic keys known only to the intended participants. As used herein, the term “secure circuit” refers to one of a class of circuits that is configured to perform one or more services and return an authenticated response to an external requester. A result returned by a secure circuit is considered to have indicia of trust exceeding that of a circuit that merely returns a result without any form of authentication. Thus, a circuit that provides data (e.g., from an untrusted memory region accessible to third-party applications) that does not authenticate the source of accessed data would not be considered a secure circuit within the meaning of this application. In embodiments disclosed herein, a secure element and a secure enclave processor are provided as examples of secure circuits. By authenticating results that are returned, such as by signing with a verifiable cryptographic signature, a secure circuit may thus provide anti-spoofing functionality. Similarly, by encrypting results using a private or secret key, a secure circuit may authenticate the source of the encrypted data (encryption may be used alone or in combination with signatures, in various embodiments). Additionally, in some cases, a secure circuit may be said to be “tamper-resistant,” which is a term of art referring to mechanisms that prevent compromise of the portions of the secure circuit that perform the one or more services. For example, a secure mailbox may be implemented such that only a portion of the secure circuit (e.g., a pre-defined memory region) is directly accessible to other circuitry. Similarly, firmware executed by a secure circuit may be encrypted, signed, and/or stored in a region that is inaccessible to other processing elements.
and transmit, to the second computing device, the generated digital certificate and the digital fingerprint to establish a secure network connection with the second computing device(certificate along with the digital signature is sent from system to mobile device validation of certificate/digital signature, ¶s39, 72,73).
[0039] In some instances, an owner of the system may wish to enable a mobile device of another user to access the system. In some embodiments, a secure element of the other user's mobile device may generate a public key pair and a corresponding certificate signing request for the public key. The other user's device may then send the certificate signing request to the secure element of the owner's mobile device, which generates a certificate for public key. The owner's mobile device may then send the generated certificate to the other user's mobile device to permit that mobile device to enable functionality of the system.
[0072] In the illustrated embodiment, system 110 then sends a certificate (system.Cert) that is encrypted using the shared secret at 322. In the particular illustrated embodiment, the shared secret includes an encryption key (KENC) and a message authorization code (KMAC). These may be shared symmetric keys derived from system.eSK/phone.ePK on the system side and phone.eSK/ system.ePK on the mobile device side. These keys may be stored on the AP 136 and the system 110's ECU and may be deleted after each transaction. In the illustrated embodiment, the notation (KENC,KMAC)(data) denotes an encryption operation using KENC and a hashing operation using KMAC (where the hash output may be used to protect the integrity of the key exchange). AP 136, in the illustrated embodiment, extracts the system public key system.PK from the encrypted certificate system.Cert using the shared secret at 324.
[0073] In the illustrated embodiment at 326, AP 136 then requests a new key pair to be generated from SE 134. In the illustrated embodiment, SE 134 generates a public/private key pair se.SK and se.PK and a corresponding certificate se.Cert at 328. In the illustrated embodiment, the certificate is a wrapper for the public key, which may describe the public key and indicate that SE 134 is authorized to issue such public keys. The certificate may be self-signed or based on a certificate from a certificate authority (e.g., if the SE 134 is an intermediate authority). SE 135 sends the certificate se.Cert to AP 136 at 332, which then encrypts the certificate using the shared secret (using KENC and KMAC techniques in the illustrated embodiment) and sends the encrypted certificate to system 110 over the secure channel at 334.
Matthias teaches ephemeral keys to generate digital certificates but does no specifically teach employing a ratcheting mechanism for key generation. Matthias does not teach wherein the generated digital certificate comprises an ephemeral, ratcheted certificate that is: valid for a defined time interval or communication session and invalidated upon expiration of the time interval or upon disconnection of the communication session; and dynamically regenerated for a subsequent communication session or pairing request by recalculating a new key pair using a key derivation function applied to a shared cryptographic seed and device identifiers, wherein the regenerated digital certificate is a self-signed, one time user certificate derived from the shared cryptographic seed and is valid for the subsequent communication session and differs from previously generated certificates;
Vass in the same field of endeavor as the invention teaches a system for encryption of communication sessions. Vass teaches wherein the generated digital certificate comprises an ephemeral, ratcheted certificate that is: valid for a defined time interval or communication session and invalidated upon expiration of the time interval or upon disconnection of the communication session(certificate generation applying a key ratcheting mechanism , ¶217).
[0217] While the distinction between users and personas is a valuable feature of the Z-Platform, the difference between the two in regard to authentication and authorization is minor. From the security perspective, user/persona sessions introduce a secondary encryption layer, also referred to as The Inner Tunnel. Users' identities are represented by certificates and their accompanying secret keys which are stored and retrieved via Z-Platform's Advanced Identity Management (AIM) mechanism. When connecting to the Z-Platform services, the client devices establish proper client certificate-verified TLS sessions then proceed to establish user sessions for their respective identities. The transport mechanism for the latter Inner Tunnel is similar to a TLS tunnel, i.e. an ephemeral key is negotiated between the client and the server and user/personaservice certificates are exchanged and mutually verified. Different from the Device Tunnel, user sessions are not tied to a single network stream (e.g. http/tcp connection) but handled as virtual streams that can last for a longer period of time with periodic rekeying and key rotations. The current design incorporates a key-ratcheting mechanism ensuring that session messages conform to Z-Platform requirements of achieving perfect forward secrecy (PFS).
and dynamically regenerated for a subsequent communication session or pairing request by recalculating a new key pair using a key derivation function applied to a shared cryptographic seed and device identifiers, (key derivation function is ratcheting thus for each session the keys and certificate generated are different¶217, the key derivation based on secery key and device identifier, ¶s284,600)
[0217] While the distinction between users and personas is a valuable feature of the Z-Platform, the difference between the two in regard to authentication and authorization is minor. From the security perspective, user/persona sessions introduce a secondary encryption layer, also referred to as The Inner Tunnel. Users' identities are represented by certificates and their accompanying secret keys which are stored and retrieved via Z-Platform's Advanced Identity Management (AIM) mechanism. When connecting to the Z-Platform services, the client devices establish proper client certificate-verified TLS sessions then proceed to establish user sessions for their respective identities. The transport mechanism for the latter Inner Tunnel is similar to a TLS tunnel, i.e. an ephemeral key is negotiated between the client and the server and user/personaservice certificates are exchanged and mutually verified. Different from the Device Tunnel, user sessions are not tied to a single network stream (e.g. http/tcp connection) but handled as virtual streams that can last for a longer period of time with periodic rekeying and key rotations. The current design incorporates a key-ratcheting mechanism ensuring that session messages conform to Z-Platform requirements of achieving perfect forward secrecy (PFS).
[0284] After the UserSessionSetup, client and server share a secret and a session ID. The session ID makes it easy to refer to a specific session secret which is used to encrypt the subsequent messages.
[0600] As described in more detail elsewhere herein, Z-Platform clients compute their own device IDs, which are essentially 32-byte unique identifiers generated from entropy sources and their digests. Upon successful registration a signed device certificate is generated, stored, and communicated back to the device for consequent communications.
wherein the regenerated digital certificate is a self-signed, one time user certificate derived from the shared cryptographic seed and is valid for the subsequent communication session and differs from previously generated certificates(certificates are based the platform acting as there own certificate authority(no central authority used), in other words it is a self-sign certificate, ¶211, in addition the system uses a key ratcheting system that provides forward security, key ratcheting mechanism as known in the cryptography art involves a certificate that changes per connection/session as each session new key is used to generate a certificate, the key advances based on the prior key like a mechanical ratchet advances to the next position, ¶217 the key dervation based on shared secret (i.e. seed), ¶284)
[0211] As described, during a successful device registration a Device Certificate is created. This certificate is used as a client certificate when establishing secure connections with the Z-Platform servers. This approach ensures an industry accepted security standard baseline, which serves as the primary tunnel for all other internally encrypted communications. All Z-Platform server components are also issued their own server certificates, which results in a two-way trust system. All Z-Platform Ecosystem certificates are rooted in a single Z-Platform Root CA certificate, for which the private key is kept isolated from all other connected elements.
[0217] While the distinction between users and personas is a valuable feature of the Z-Platform, the difference between the two in regard to authentication and authorization is minor. From the security perspective, user/persona sessions introduce a secondary encryption layer, also referred to as The Inner Tunnel. Users' identities are represented by certificates and their accompanying secret keys which are stored and retrieved via Z-Platform's Advanced Identity Management (AIM) mechanism. When connecting to the Z-Platform services, the client devices establish proper client certificate-verified TLS sessions then proceed to establish user sessions for their respective identities. The transport mechanism for the latter Inner Tunnel is similar to a TLS tunnel, i.e. an ephemeral key is negotiated between the client and the server and user/personaservice certificates are exchanged and mutually verified. Different from the Device Tunnel, user sessions are not tied to a single network stream (e.g. http/tcp connection) but handled as virtual streams that can last for a longer period of time with periodic rekeying and key rotations. The current design incorporates a key-ratcheting mechanism ensuring that session messages conform to Z-Platform requirements of achieving perfect forward secrecy (PFS).
[0284] After the UserSessionSetup, client and server share a secret and a session ID. The session ID makes it easy to refer to a specific session secret which is used to encrypt the subsequent messages.
It would have been obvious to a person of ordinary skill in the art at the time of the effective filing of the instant application to modify Matthia’s digital certificate creation process with a ratcheting key derivation algorithm as part of certificate generation as taught by Vass. The reason for this modification would be to implement secured communication between devices that provides forward secrecy.
Regarding claims 2 and 15 , Mathias teaches wherein the code is further executable by the processor to: receive, from the second computing device, a second digital certificate and a second digital fingerprint associated with the second computing device(mutual authentication performed based on TLS protocol, or on other words mutual TLS or mTLS where both client and server, or mobile device and system exchange certificates and digital signature and validate each other as part of creating a secure connection, ¶s118,243)
verify the second digital certificate and the second digital fingerprint based on the first key and the key pair(mutual authentication performed based on TLS protocol, or on other words mutual TLS or mTLS where both client and server, or mobile device and system exchange certificates and digital signature and validate each other as part of creating a secure connection, ¶s118,243)
and establish, in response to verifying the second the second digital certificate and the second digital fingerprint, the secure network connection with the second computing device(mutual authentication performed based on TLS protocol, or on other words mutual TLS or mTLS where both client and server, or mobile device and system exchange certificates and digital signature and validate each other as part of creating a secure connection, ¶s118,243)
[0118] At 710, in the illustrated embodiment, in response to receiving a first request to perform a pairing operation with a system, a mobile device establishes a first shared encryption key with the system. This may include establishing an ephemeral key pair and deriving a shared secret based on the ephemeral key pair. Deriving the shared secret may use ECDH or some other asymmetric encryption technique. The request to perform the pairing operation may be received from the system or from a user (e.g., via an input component). Note that various embodiments are described herein with reference to a vehicle and a mobile phone phone. These devices are included for purposes of illustration but are not intended to limit the scope of the present disclosure. In various embodiments, the disclosed techniques may be used for mutual authentication between two or more of various types of devices. For example, similar techniques may be used to authenticate devices with paired wearable devices, distributed sensors, interne of things devices, etc.
[0243]…The secure session may use standard protocol like TLS such that the device is able to authenticate the server. Once this session is established, the device may use the secure element to sign challenges provided by the system and commands to be executed by the system. The system manufacturer's server, acting as a proxy, may check packet formatting and signatures are correct before transmitting requests to the system. Firewall-type protection against denial of service or ill-formatted packet may also be handled by the system manufacturer's server. In some embodiments, TLS server authentication might be upgraded with client authentication after the device successfully signs a server challenge with a valid key, which may help filter DOS attacks at the cost of increased complexity.
Regarding claims 3 and 16, Matthias teaches, wherein the code is further executable by the processor to associate a validity time period with at least one of the key pair and the calculated digital fingerprint for the apparatus/computing device(keys and certificate may be valid until an expiration date/time, ¶309) .
[0309] At 3006, the mobile device OS 2120 logs in to server 3010 and fetches an owner password. At 3008, SRP is used to create a secure channel and system 110 provides digital key configuration data. This configuration information may include various fields, e.g., indicating what type of transactions are allowed, system metadata, start date, expiration date, public keys, a system identifier, etc. In some embodiments, system 110 is configured to reject pairing unless the mobile device properly attests that the digital key was created according to the configuration data.
Regarding claims 4 and 17, Matthias teaches, wherein the code is further executable by the processor to invalidate the at least one of the key pair and the calculated digital fingerprint for the apparatus in response to expiration of the validity time period(since keys and certificate created are ephemeral they are invalidated after expiration, ¶69).
[0069] In the illustrated embodiment, the key pair includes an ephemeral public key system.ePK and an ephemeral secret key system.eSK. The keys may be “ephemeral” in the sense that they are limited-use, e.g., valid only for a certain number of uses (including embodiments in which they are valid for only a single use) or valid for a certain time interval. Ephemeral keys may be deleted at the end of each transaction. Because ephemeral keys are invalid after expiration, this may prevent the keys from being re-used by an unauthorized individual if they are somehow intercepted.
Regarding claim 8, Matthias teaches wherein, in response to a request to initiate the secure pairing process with the second computing device, the code is further executable by the processor to generate the key pair for the apparatus, the key pair comprising a public key and a private key.
[0068] In the illustrated embodiment, at 306 system 110 verifies the authentication information and, in response, generates an ephemeral key pair. In the illustrated embodiment, system 110 switches to a “pairing in progress state” at this point. Note that in other embodiments, other states may be used and the states may be entered or exited at different points than shown.
[0069] In the illustrated embodiment, the key pair includes an ephemeral public key system.ePK and an ephemeral secret key system.eSK. The keys may be “ephemeral” in the sense that they are limited-use, e.g., valid only for a certain number of uses (including embodiments in which they are valid for only a single use) or valid for a certain time interval. Ephemeral keys may be deleted at the end of each transaction. Because ephemeral keys are invalid after expiration, this may prevent the keys from being re-used by an unauthorized individual if they are somehow intercepted.
Regarding claim 9, Matthias teaches wherein the code is further executable by the processor to transmit the public key for the apparatus to the second computing device.
[0071] In response to initiation of the pairing procedure, at 312 AP 136 also generates an ephemeral key pair phone.ePK and phone.eSK, in the illustrated embodiment. In the illustrated embodiment, system 110 and AP 135 then exchange their respective generated ephemeral public keys, system.ePK and phone.ePK at 314 and 316. Each device then derives a shared secret based on the exchanged public keys and their respective secret keys at 318. As discussed above, ECDH may be used to derive the shared secret. At this point in the process, in the illustrated embodiment, an unauthenticated secure channel has been established between the system 110 and the mobile device 130 using ephemeral keys. In other embodiments, other techniques may be used to establish a shared secret or key. The disclosed techniques for obtaining a shared secret are disclosed for purposes of illustration, but are not intended to limit the scope of the present disclosure.
Regarding claim 10, Matthias teaches wherein the code is further executable by the processor to calculate a shared secret seed using a key agreement protocol between the apparatus and the second computing device, the key agreement protocol comprising an elliptic curve cryptography protocol.
[0084] In the illustrated embodiment at 402, system 110 starts communication with AP 136. In some embodiments, this includes sending polling messages (e.g., NFC anti-collision enhanced contactless polling (ECP) messages). In other embodiments, other communication initiation techniques may be used. In response, AP 136 generates an ephemeral key pair phone.eSK and phone.ePK, in the illustrated embodiment at 404 (although other processing elements such as SE 134 may generate the ephemeral key pair in other embodiments). Examples of key pairs include elliptic curve cryptography (ECC) pairs, pairs generated using AES encryption, etc. In the illustrated embodiment, AP 136 sends this key pair and channel negotiation options to system 110 at 406. In some embodiments, in response to determining that it is within communication distance with system 110, mobile device 130 may automatically prompt the user for input of one or more commands for system 110.
[0190] At 1022, in the illustrated embodiment, mobile device 130 generates a derived shared secret, generates a signature, and encrypts the signature based on the derived shared secret. In some embodiments, this includes to generate KAEseed=KDF(DH(system.ePK, phone.eSK), system.ePK|phone.ePK|system.PK). In this example, the Diffie Hellman function DH is one example of a key exchange function used to generate a shared secret and the key derivation function KDF generates a derived shared secret based on the output of the key exchange function, and the public keys system.ePK, phone.ePK, and system.PK. In some embodiments, mobile device 130 also defines a diversifier=transaction.identifier|phone.ePK|system.ePK|systemIdentifier|system.PK. In some embodiments, mobile device 130 computes KAEe1:KAEm1:IVe1=KDF(KAEseed, diversifier|“phone to system”) and computes KAEe2:KAEm2:IVe2=KDF(KAEseed, diversifier|“system to phone”). These derived symmetric keys may be used to encrypt information identifying the phone and/or confidential payloads, which may increase security of such information.
Regarding claim 11, Matthias teaches wherein the code is further executable by the processor to calculate a second key based on identifiers for the apparatus and the second computing device(symmetric key is created based on shared secret of the system and mobile public keys and other device information, ¶s159,160,190).
[0159] systemIdentifier, in some embodiments, is a unique identifier of the system. For NFC transactions it may be protected by the reach of the RF field. For BT transactions, it may rely on the privacy protection of the BT channel. On device side it may be used to determine the long term public key of the system.
[0160] phoneIdentifier, in some embodiments, is a unique identifier of the device. In some embodiments, it is protected for privacy during the transaction by sending it in a secure channel after the phone has verified the system identity. It may be used on system side to select the device public key to verify the signature transaction.Type reader-determined value that indicates which flow shall be taken, fast or standard/full.
[0190] At 1022, in the illustrated embodiment, mobile device 130 generates a derived shared secret, generates a signature, and encrypts the signature based on the derived shared secret. In some embodiments, this includes to generate KAEseed=KDF(DH(system.ePK, phone.eSK), system.ePK|phone.ePK|system.PK). In this example, the Diffie Hellman function DH is one example of a key exchange function used to generate a shared secret and the key derivation function KDF generates a derived shared secret based on the output of the key exchange function, and the public keys system.ePK, phone.ePK, and system.PK. In some embodiments, mobile device 130 also defines a diversifier=transaction.identifier|phone.ePK|system.ePK|systemIdentifier|system.PK. In some embodiments, mobile device 130 computes KAEe1:KAEm1:IVe1=KDF(KAEseed, diversifier|“phone to system”) and computes KAEe2:KAEm2:IVe2=KDF(KAEseed, diversifier|“system to phone”). These derived symmetric keys may be used to encrypt information identifying the phone and/or confidential payloads, which may increase security of such information.
Regarding claim 12, Matthias teaches wherein the code is further executable by the processor to generate the digital certificate using a key generated using elliptic curve cryptography (“ECC”) based on the second key and a dynamically determined generator ECC point.
[0084] In the illustrated embodiment at 402, system 110 starts communication with AP 136. In some embodiments, this includes sending polling messages (e.g., NFC anti-collision enhanced contactless polling (ECP) messages). In other embodiments, other communication initiation techniques may be used. In response, AP 136 generates an ephemeral key pair phone.eSK and phone.ePK, in the illustrated embodiment at 404 (although other processing elements such as SE 134 may generate the ephemeral key pair in other embodiments). Examples of key pairs include elliptic curve cryptography (ECC) pairs, pairs generated using AES encryption, etc. In the illustrated embodiment, AP 136 sends this key pair and channel negotiation options to system 110 at 406. In some embodiments, in response to determining that it is within communication distance with system 110, mobile device 130 may automatically prompt the user for input of one or more commands for system 110.
[0201] In some embodiments, various modification may be made to the transactions of FIG. 10 to increase performance. For example, compact or compressed form may be used for ECC points, e.g., to reduce public key sizes. In some embodiments, a minimum amount of data may be transferred that is needed to reconstruct system.eCert (e.g., rather than the fill eCert). In some embodiments, data may be prefetched, such as the ephemeral keys, systemIdentifier, transaction.ID, etc. Further, selection of an efficient EC curve may also improve performance.
Regarding claim 13, Matthias teaches wherein the secure pairing process comprises a mutual transport layer security (“mTLS”) protocol(mutual authentication performed based on TLS protocol, or on other words mutual TLS or mTLS where both client and server, or mobile device and system exchange certificates and digital signature and validate each other as part of creating a secure connection, ¶s118,243)
[0118] At 710, in the illustrated embodiment, in response to receiving a first request to perform a pairing operation with a system, a mobile device establishes a first shared encryption key with the system. This may include establishing an ephemeral key pair and deriving a shared secret based on the ephemeral key pair. Deriving the shared secret may use ECDH or some other asymmetric encryption technique. The request to perform the pairing operation may be received from the system or from a user (e.g., via an input component). Note that various embodiments are described herein with reference to a vehicle and a mobile phone phone. These devices are included for purposes of illustration but are not intended to limit the scope of the present disclosure. In various embodiments, the disclosed techniques may be used for mutual authentication between two or more of various types of devices. For example, similar techniques may be used to authenticate devices with paired wearable devices, distributed sensors, interne of things devices, etc.
[0243]…The secure session may use standard protocol like TLS such that the device is able to authenticate the server. Once this session is established, the device may use the secure element to sign challenges provided by the system and commands to be executed by the system. The system manufacturer's server, acting as a proxy, may check packet formatting and signatures are correct before transmitting requests to the system. Firewall-type protection against denial of service or ill-formatted packet may also be handled by the system manufacturer's server. In some embodiments, TLS server authentication might be upgraded with client authentication after the device successfully signs a server challenge with a valid key, which may help filter DOS attacks at the cost of increased complexity.
Claims 5 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Mathias/Vass as applied to claims 4 and 17 above, and further in view of Matthias et al US 2017/0359314 hereafter Matthias314.
Regarding claim 5 and 18. Mathias/Vass teach expiring certificates and ephemeral keys but does not specifically teach wherein invalidation of the at least one of the key pair and the calculated digital fingerprint for the apparatus disconnects the secure network connection with the second computing device. Mathias314 in the same field of endeavor as the invention teaches a system for secure connection and data transfer between devices. Mathias314 teaches wherein invalidation of the at least one of the key pair and the calculated digital fingerprint for the apparatus disconnects the secure network connection with the second computing device(either device can end session i.e. disconnect by invalidating session key, ¶62) .
[0062] In some embodiments, communication with a given accessory can be limited to authorized controllers. The protocol can specify one or more mechanisms (including mechanisms referred to herein as “pair setup” and “pair add”) for establishing a “pairing” between a controller and a given accessory under circumstances that provide a high degree of confidence that the user intends for the controller to be able to control the accessory. Pair setup can include an out-of-band information exchange (e.g., the user can enter a numerical or alphanumeric PIN or passcode provided by the accessory into an interface provided by the controller) to establish a shared secret. This shared secret can be used to support secure exchange of “long-term” public keys between the controller and the accessory, and each device can store the long-term public key received from the other, so that an established pairing can be persistent. After a pairing is established, the paired controller is considered authorized, and thereafter, the controller and accessory can go in and out of communication as desired without losing the established pairing. When a controller attempts to communicate with or control an accessory, a “pair verify” process can first be performed to verify that an established pairing exists (as would be the case, e.g., where the controller previously completed pair setup with the accessory). The pair verify process can include each device demonstrating that it is in possession of a long-term private key corresponding to the long-term public key that was exchanged during pair setup and can further include establishing a new shared secret or session key to encrypt all communications during a “pair-verified” session, (also referred to herein as a verified session). During a pair-verified session, a controller that has appropriate privileges can perform a “pair add” process to establish another pairing with the accessory on behalf of another controller. Either device can end a pair-verified session at any time simply by destroying or invalidating its copy of the session key.
It would have been obvious to a person of ordinary skill in the art at the time of the effective filing of the instant application to modify Matthias/Vass with ending a connection by invalidating the session key as taught by Mathias314. The reason for this modification would be to provide a method of disconnecting a session between devices and protect against reuse of old keys.
Claims 6 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Matthias/Vass as applied to claims 1 and 14 above, and further in view of Monica US 2013/0182845.
Regarding claim 6 and 19, Matthias/Vass teach that the certificates/keys and signatures expire since they are based on ephemeral key generation bus does not specifically teach wherein the code is further executable by the processor to invalidate the at least one of the key pair and the calculated digital fingerprint for the apparatus in response to disconnection of the secure network connection with the second computing device. Monica in the same field of endeavor as the invention teaches a system for securing device to device connection for facilitating financial transactions. Monica teaches wherein the code is further executable by the processor to invalidate the at least one of the key pair and the calculated digital fingerprint for the apparatus in response to disconnection of the secure network connection with the second computing device(disconnection from between device and device acting a hotspot causes expiring of the keys, ¶s7,9).
[0007] Implementations may include one or more of the following features. Sending the request to the server may include sending a geographic location, current timestamp, a random number, or unique identification of the first mobile computing device. Authenticating the first mobile computing device with the server may include authenticating by the first mobile computing device logging into the server. A list of mobile computing devices connected to the Wi Fi hot spot may be received in the first mobile computing device. The session key may expire after a predetermined amount of time. The session key may expire when a mobile device connected to the Wi Fi hot spot is disconnected. The mobile computing devices and Wi Fi hot spot are in a vehicle or in the same business establishment, e.g., a restaurant. The trusted certificate may be a Transport Layer Security (TLS) certificate.
[0009] Implementations may include one or more of the following features. Verifying that the first mobile computing device is trusted may include determining the first mobile computing device has established a session with the server. After verifying that the second mobile computing device is trusted, the second mobile computing device may join the session. Verifying that the second mobile computing device is trusted may include determining the distance between the first mobile computing device and the second mobile computing device is within a predetermined distance. Verifying that the second mobile computing device is trusted may include determining a first unique identification of the first mobile computing device exists in a database. The trusted certificate may be a TLS certificate. The public or private key may expire after a predetermined amount of time. The public or private key may expire when the first mobile computing device or the second mobile computing device disconnect from the Wi Fi hot spot. The first request may include first metadata indicating a location, a timestamp, a random number, or a unique identification, and the second request may include second metadata matching the first metadata.
It would have been obvious to a person of ordinary skill in the art at the time of the effective filing of the instant application to modify Matthias/Vass with ending expire/invalidate the key upon ending the connection/session as taught by Monica. The reason for this modification would be to provide a method of disconnecting a session between devices and protect against reuse of old keys.
Claims 7 is rejected under 35 U.S.C. 103 as being unpatentable over Mathias/Vass as applied to claim and further in view of obvious modification by one or ordinary skill based on the teaching of Mathias.
Regarding claim 7, Matthias/Vass teaches wherein the secure pairing process is between a first plugin executing on the apparatus
[0056] Applets 226, in one embodiment, are executable to perform enrollment of mobile device 130 and authentication with a reader. With respect to enrollment, applets 226 may be executable to generate public-key pairs and obtain corresponding certificates, which may be stored in memory 224 as public-key information 228.
Matthias teaches a plugin for the apparatus/mobile device but does not specifically teach the software that performs key generation and secure connection protocol is performed using a plug in. Thus, Matthias does not specifically teach a second plugin executing on the second computing device. A person of ordinary skill in the art having an understanding of the benefits of software application implemented as installable applets such as the mobile device applets(¶56 Matthias) of Matthias would be motivated to further modify the system side key generation and secure connection software as a installable applet. The reason for such a modification would be to implement a secure connection software that is easily updateable with application that can perform new protocols and algorithms for secure connection and key generation.
Claims 1-4, 8-17 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Mathias US 2020/0052905, further in view of Vass US 2020/0204527 and Hartsock US 2020/0012527.
Regarding claims 1,14 and 20, Matthias teaches a method, a computer program product comprising executable code and an apparatus comprising: a processor; and a memory that stores code executable by the processor to: receive, at the apparatus during a secure pairing process with a second computing device, a first key associated with the second computing device(first device/mobile device and second device/system initiate pairing process and exchange public keys, ¶36).
[0036] In various embodiments, the mobile device initially performs a pairing procedure with the system. This procedure may include the mobile device exchanging short-lived public key pairs with the system and a processor of the mobile device generating a shared secret with the system based on the exchanged keys (e.g., using elliptic curve Diffie-Hellman (ECDH)). A secure circuit of the mobile device may also generate a public key pair to allow the system to authenticate the mobile device. The secure circuit may be a secure element, for example. As used herein, the term “secure element” is to be interpreted according to its understood meaning in the art, which includes circuitry (e.g., often a single-chip microcontroller) that is configured to store information in a tamper-resistant manner that resists unauthorized extraction of that information. Non-limiting examples of form factors for secure elements include UICC, embedded SE, and microSD. In some embodiments, the secure element is also used for other types of transactions such as payment transactions, for example. For payment transactions, the secure element may cryptographically store data for payment instruments (e.g., credit cards) and owners (e.g., cardholders), entry to physical locations or buildings, transmit access, etc. In some embodiments, at least a portion of secure element functionality may be cloud-based. In these embodiments, the secure element on a device may store virtual information which may be used to retrieve actual required information that is stored on a server. In some embodiments, other types of secure circuits or secure processors may perform functionality described as being performed by a secure element, including, for example, a secure enclave processor discussed below.
generate a digital certificate based on a key pair associated with the apparatus, the key pair dynamically generated in response to initiation of the secure pairing process(a certificate is create for authentication of the system, ¶37)
[0037] After the key exchange, the mobile device may then encrypt a certificate for the key pair using the private key and send the encrypted certificate to the system. The mobile device may then display a value derived based on the public key pair and ask the user of the mobile device to confirm that the value is also displayed on a display of the system, which may derive the value based on the public key in the certificate.
calculate a digital fingerprint for the apparatus based on the first key associated with the second computing device and at least one of the keys of the key pair associated with the apparatus(a digital signature is created by signing a verifiable cryptographic signature i.e fingerprint, ¶42)
[0042] As used herein, the term “secure channel” refers to either a dedicated path for communicating data (i.e., a path shared by only the intended participants) or communicating encrypted data or signed data using cryptographic keys known only to the intended participants. As used herein, the term “secure circuit” refers to one of a class of circuits that is configured to perform one or more services and return an authenticated response to an external requester. A result returned by a secure circuit is considered to have indicia of trust exceeding that of a circuit that merely returns a result without any form of authentication. Thus, a circuit that provides data (e.g., from an untrusted memory region accessible to third-party applications) that does not authenticate the source of accessed data would not be considered a secure circuit within the meaning of this application. In embodiments disclosed herein, a secure element and a secure enclave processor are provided as examples of secure circuits. By authenticating results that are returned, such as by signing with a verifiable cryptographic signature, a secure circuit may thus provide anti-spoofing functionality. Similarly, by encrypting results using a private or secret key, a secure circuit may authenticate the source of the encrypted data (encryption may be used alone or in combination with signatures, in various embodiments). Additionally, in some cases, a secure circuit may be said to be “tamper-resistant,” which is a term of art referring to mechanisms that prevent compromise of the portions of the secure circuit that perform the one or more services. For example, a secure mailbox may be implemented such that only a portion of the secure circuit (e.g., a pre-defined memory region) is directly accessible to other circuitry. Similarly, firmware executed by a secure circuit may be encrypted, signed, and/or stored in a region that is inaccessible to other processing elements.
and transmit, to the second computing device, the generated digital certificate and the digital fingerprint to establish a secure network connection with the second computing device(certificate along with the digital signature is sent from system to mobile device validation of certificate/digital signature, ¶s39, 72,73).
[0039] In some instances, an owner of the system may wish to enable a mobile device of another user to access the system. In some embodiments, a secure element of the other user's mobile device may generate a public key pair and a corresponding certificate signing request for the public key. The other user's device may then send the certificate signing request to the secure element of the owner's mobile device, which generates a certificate for public key. The owner's mobile device may then send the generated certificate to the other user's mobile device to permit that mobile device to enable functionality of the system.
[0072] In the illustrated embodiment, system 110 then sends a certificate (system.Cert) that is encrypted using the shared secret at 322. In the particular illustrated embodiment, the shared secret includes an encryption key (KENC) and a message authorization code (KMAC). These may be shared symmetric keys derived from system.eSK/phone.ePK on the system side and phone.eSK/ system.ePK on the mobile device side. These keys may be stored on the AP 136 and the system 110's ECU and may be deleted after each transaction. In the illustrated embodiment, the notation (KENC,KMAC)(data) denotes an encryption operation using KENC and a hashing operation using KMAC (where the hash output may be used to protect the integrity of the key exchange). AP 136, in the illustrated embodiment, extracts the system public key system.PK from the encrypted certificate system.Cert using the shared secret at 324.
[0073] In the illustrated embodiment at 326, AP 136 then requests a new key pair to be generated from SE 134. In the illustrated embodiment, SE 134 generates a public/private key pair se.SK and se.PK and a corresponding certificate se.Cert at 328. In the illustrated embodiment, the certificate is a wrapper for the public key, which may describe the public key and indicate that SE 134 is authorized to issue such public keys. The certificate may be self-signed or based on a certificate from a certificate authority (e.g., if the SE 134 is an intermediate authority). SE 135 sends the certificate se.Cert to AP 136 at 332, which then encrypts the certificate using the shared secret (using KENC and KMAC techniques in the illustrated embodiment) and sends the encrypted certificate to system 110 over the secure channel at 334.
Matthias teaches ephemeral keys to generate digital certificates but does no specifically teach employing a ratcheting mechanism for key generation. Matthias does not teach wherein the generated digital certificate comprises an ephemeral, ratcheted certificate that is: valid for a defined time interval or communication session and invalidated upon expiration of the time interval or upon disconnection of the communication session; and dynamically regenerated for a subsequent communication session or pairing request by recalculating a new key pair using a key derivation function applied to a shared cryptographic seed and device identifiers, wherein the regenerated digital certificate is a self-signed, one time user certificate derived from the shared cryptographic seed and is valid for the subsequent communication session and differs from previously generated certificates;
Vass in the same field of endeavor as the invention teaches a system for encryption of communication sessions. Vass teaches wherein the generated digital certificate comprises an ephemeral, ratcheted certificate that is: valid for a defined time interval or communication session and invalidated upon expiration of the time interval or upon disconnection of the communication session(certificate generation applying a key ratcheting mechanism , ¶217).
[0217] While the distinction between users and personas is a valuable feature of the Z-Platform, the difference between the two in regard to authentication and authorization is minor. From the security perspective, user/persona sessions introduce a secondary encryption layer, also referred to as The Inner Tunnel. Users' identities are represented by certificates and their accompanying secret keys which are stored and retrieved via Z-Platform's Advanced Identity Management (AIM) mechanism. When connecting to the Z-Platform services, the client devices establish proper client certificate-verified TLS sessions then proceed to establish user sessions for their respective identities. The transport mechanism for the latter Inner Tunnel is similar to a TLS tunnel, i.e. an ephemeral key is negotiated between the client and the server and user/personaservice certificates are exchanged and mutually verified. Different from the Device Tunnel, user sessions are not tied to a single network stream (e.g. http/tcp connection) but handled as virtual streams that can last for a longer period of time with periodic rekeying and key rotations. The current design incorporates a key-ratcheting mechanism ensuring that session messages conform to Z-Platform requirements of achieving perfect forward secrecy (PFS).
and dynamically regenerated for a subsequent communication session or pairing request by recalculating a new key pair using a key derivation function applied to a shared cryptographic seed and device identifiers, (key derivation function is ratcheting thus for each session the keys and certificate generated are different¶217, the key derivation based on secery key and device identifier, ¶s284,600)
[0217] While the distinction between users and personas is a valuable feature of the Z-Platform, the difference between the two in regard to authentication and authorization is minor. From the security perspective, user/persona sessions introduce a secondary encryption layer, also referred to as The Inner Tunnel. Users' identities are represented by certificates and their accompanying secret keys which are stored and retrieved via Z-Platform's Advanced Identity Management (AIM) mechanism. When connecting to the Z-Platform services, the client devices establish proper client certificate-verified TLS sessions then proceed to establish user sessions for their respective identities. The transport mechanism for the latter Inner Tunnel is similar to a TLS tunnel, i.e. an ephemeral key is negotiated between the client and the server and user/personaservice certificates are exchanged and mutually verified. Different from the Device Tunnel, user sessions are not tied to a single network stream (e.g. http/tcp connection) but handled as virtual streams that can last for a longer period of time with periodic rekeying and key rotations. The current design incorporates a key-ratcheting mechanism ensuring that session messages conform to Z-Platform requirements of achieving perfect forward secrecy (PFS).
[0284] After the UserSessionSetup, client and server share a secret and a session ID. The session ID makes it easy to refer to a specific session secret which is used to encrypt the subsequent messages.
[0600] As described in more detail elsewhere herein, Z-Platform clients compute their own device IDs, which are essentially 32-byte unique identifiers generated from entropy sources and their digests. Upon successful registration a signed device certificate is generated, stored, and communicated back to the device for consequent communications.
It would have been obvious to a person of ordinary skill in the art at the time of the effective filing of the instant application to modify Matthia’s digital certificate creation process with a ratcheting key derivation algorithm as part of certificate generation as taught by Vass. The reason for this modification would be to implement secured communication between devices that provides forward secrecy.
The combination of Matthias/Vass does not specifically teach self-signing and ratcheting certification and this does not teach wherein the regenerated digital certificate is a self-signed, one time user certificate derived from the shared cryptographic seed and is valid for the subsequent communication session and differs from previously generated certificates. Hartsock in the same field of endeavor as the invention teaches a system for securing communication in a computing network. Hartsock teaches wherein the regenerated digital certificate is a self-signed, one time user certificate derived from the shared cryptographic seed and is valid for the subsequent communication session and differs from previously generated certificates(a ratcheting key derivation function is used with self-signed certificates to generate a series of keys with a shared secret, for certificate that change session to session, ¶s75,76,91, 92,93).
[0075] Public-key certificates, including certificates that follow the X.509 ITU-T standard, are frequently used in secure communications for verifiably binding a public key to a name or identifier, such as a business entity name or a business or personal email address. FIG. 13 illustrates the structure of an X.509 public-key certificate. The X.509 certificate 1302 is essentially a data record that contains a sequence of standard fields that contain information needed to employ the certificate for verifying the binding, or association, of a user identifier or system identifier with a public key. These fields include a certificate version number 1304, a serial number 1306 that is unique with respect to a particular certificate authority that issues public-key certificates, an encoding of an identifier for the cryptographic method used to compute a signature over the certificate 1308, information that identifies the issuer of the certificate 1310, two date and time values 1312 that indicate the beginning date and time at which the certificate becomes valid and the ending date and time at which the validity of the certificate ends, identifying information for the user or system that is bound by the certificate to a public key 1313, a group of fields that indicate the cryptographic algorithm for which the public key is used and that include the public key 1314, optional fields 1316, referred to as extensions, that include additional information, an indication of the signature algorithm 1318, and the signature, computed by the issuing entity over the remaining fields of the certificate 1320. In some cases, the additional information section can contain indications of a security protocol to be used when establishing a secure connection.
[0076] In general, public-key certificates are issued by trusted computer systems within entrusted organizations known as “Certificate Authorities” (“CAs”). CAs are well-known certificate-issuing organizations that issue public/private key pairs, including corresponding public-key certificates, as a commercial service. These organizations employ various due-diligence information-gathering techniques to verify the identity of a requesting entity prior to issuing a key pair and public-key certificate. Large organizations, such as universities or big companies, may perform the function of a CA in order to generate public-key certificates for their use, referred to as “self-signing.”
[0091] FIG. 21 illustrates private/public encryption key generation and distribution based on elliptic-curve-derive finite fields. The private key d is randomly selected from the set of integers {1, . . . , |C|−1}, where C is a cyclic group derived from an elliptic-curve-derive finite field, as indicated by expression 2102. The public-key is computed as dG, where G is a generator for C, as indicated by expression 2104. Again, the expression dG indicates scaler multiplication of a cyclic-group element by the scaler value d, as discussed above with reference to FIG. 20. Diagram 2106 illustrates secure generation of a secret value S by two communicating entities A 2108 and B 2110 using illustration conventions similar to those used in FIG. 15. Both entities generate private keys, d.sub.a for entity A and d.sub.b for entity B, and corresponding public keys H.sub.a and H.sub.b, exchange the public keys, and then compute a shared secret S by a modified Diffie-Hellman key-exchange method. Note that, as indicated by expression 2107, the secret S.sub.a, d.sub.aH.sub.b, computed by entity A is equal to the secret S.sub.b, d.sub.bH.sub.a, computed by entity B, since multiplication of scalers is commutative. The method depends on easy computation of public keys and the fact that determining d from G and dG is difficult for cyclic groups C where |C| is large. As discussed above, the secret S can be used as a symmetric encryption key or can be used to generate a symmetric key.
[0092] FIG. 22 illustrates an encryption-key ratchet system. The encryption-key ratchet system uses the above-mentioned elliptic-curve-based private/public key generation and distribution method. In FIG. 22, the left-hand flow diagram 2202 represents the ratchet logic for a first communicating entity and the right-hand flow diagram 2204 represents the ratchet logic for a second communicating entity. The communicating entities continuously generate new symmetric encryption keys as they exchange messages so that even were a malicious, eavesdropping third-party to obtain a single symmetric encryption key in the sequence of symmetric encryption keys generated and used by the two communicating parties, the third-party would be able, at most, to decrypt one message and would not be able to generate any other of the encryption keys in the sequence of encryption keys from the single obtained encryption key. Both communicating entities receive the parameters for a cyclic group derived from an elliptic-curve-derived finite field in steps 2206 and 2207. In steps 2208 and 2209, the first communicating entity, referred to as the sending entity s, generates a new private key d, and a new public key H.sub.s and the second communicating entity, referred to as the receiving entity r, generates a new private key d.sub.r and a new public key H.sub.r. In steps 2210 and 2211, the sending entity s sends a message to receiving entity r that includes the newly generated public key H.sub.s and, in steps 2212-2213, the receiving entity r sends a message that contains the newly generated public key H.sub.r to sending entity s. Up to this point, the messages are sent in an encrypted form, since no symmetric encryption keys have been generated. The following steps are iteratively repeated to transmit messages back and forth between the two communicating entities. In step 2214, sending entity s sets the new sending key to d.sub.sH.sub.r and receiving entity r sets anew receiving key to d.sub.rH.sub.s in step 2215. Note that, as discussed above with reference to FIG. 21, d.sub.sH.sub.r=d.sub.rH.sub.s. In step 2216, sending entity s generates a new private key d.sub.s and a new public key H.sub.s while, in step 2217, receiving entity are generates a new private key d.sub.r and a new public key H.sub.r. In step 2218, sending entity s sets a new receiving key to d.sub.sH.sub.r and, in step 2219, receiving entity r sets a new sending key to d.sub.rH.sub.s. In step 2220, sending entity s sends a new message, which includes the newly generated public key H.sub.s and which is encrypted with the sending key generated in step 2214, to receiving entity r, while receiving entity r, in step 2221, receives the encrypted message from entity s and decrypts the received message using the receiving key generated in step 2215. In step 2223, the receiving entity r sends a message, which contains the new public key H.sub.r generated in step 2217 and which is encrypted using the sending key generated in step 2219, to sending entity s, which receives the encrypted message in step 2222 and decrypts the received message using the receiving key generated in step 2218. The two communicating entities s and r can continue to send and receive messages by subsequent iterations of steps 2214-2223.
[0093] FIG. 23 illustrates a second type of sequential key-generation technique. This technique uses the above-discussed key-derivation function. As shown in FIG. 23, a KDF function 2302 is supplied with an initial KDF_key 2304 and an input value 2306 and produces an output value 2308 that can be used as an encryption key 2310 or from which encryption key can be derived by additional processing. The output value 2308 is additionally input to the KDF function 2312 along with an input value 2314 to generate another output value 2316 that can be used as an encryption key or from which an encryption key can be derived from additional processing 2318. These calls to the KDF function continue for an arbitrary number of iterations to generate a sequence of encryption keys 2310, 2318, and 2320-2322.
It would have been obvious to a person of ordinary skill in the art at the time of the effective filing of the instant application to modify Matthia/Vass digital certificate creation process and ratcheting key derivation algorithm with a combination of self-signing and ratcheting techniques. The reason for this modification would be to implement a metho of encryption that provides secured communication with forward secrecy.
Regarding claims 2 and 15 , Mathias teaches wherein the code is further executable by the processor to: receive, from the second computing device, a second digital certificate and a second digital fingerprint associated with the second computing device(mutual authentication performed based on TLS protocol, or on other words mutual TLS or mTLS where both client and server, or mobile device and system exchange certificates and digital signature and validate each other as part of creating a secure connection, ¶s118,243)
verify the second digital certificate and the second digital fingerprint based on the first key and the key pair(mutual authentication performed based on TLS protocol, or on other words mutual TLS or mTLS where both client and server, or mobile device and system exchange certificates and digital signature and validate each other as part of creating a secure connection, ¶s118,243)
and establish, in response to verifying the second the second digital certificate and the second digital fingerprint, the secure network connection with the second computing device(mutual authentication performed based on TLS protocol, or on other words mutual TLS or mTLS where both client and server, or mobile device and system exchange certificates and digital signature and validate each other as part of creating a secure connection, ¶s118,243)
[0118] At 710, in the illustrated embodiment, in response to receiving a first request to perform a pairing operation with a system, a mobile device establishes a first shared encryption key with the system. This may include establishing an ephemeral key pair and deriving a shared secret based on the ephemeral key pair. Deriving the shared secret may use ECDH or some other asymmetric encryption technique. The request to perform the pairing operation may be received from the system or from a user (e.g., via an input component). Note that various embodiments are described herein with reference to a vehicle and a mobile phone phone. These devices are included for purposes of illustration but are not intended to limit the scope of the present disclosure. In various embodiments, the disclosed techniques may be used for mutual authentication between two or more of various types of devices. For example, similar techniques may be used to authenticate devices with paired wearable devices, distributed sensors, interne of things devices, etc.
[0243]…The secure session may use standard protocol like TLS such that the device is able to authenticate the server. Once this session is established, the device may use the secure element to sign challenges provided by the system and commands to be executed by the system. The system manufacturer's server, acting as a proxy, may check packet formatting and signatures are correct before transmitting requests to the system. Firewall-type protection against denial of service or ill-formatted packet may also be handled by the system manufacturer's server. In some embodiments, TLS server authentication might be upgraded with client authentication after the device successfully signs a server challenge with a valid key, which may help filter DOS attacks at the cost of increased complexity.
Regarding claims 3 and 16, Matthias teaches, wherein the code is further executable by the processor to associate a validity time period with at least one of the key pair and the calculated digital fingerprint for the apparatus/computing device(keys and certificate may be valid until an expiration date/time, ¶309) .
[0309] At 3006, the mobile device OS 2120 logs in to server 3010 and fetches an owner password. At 3008, SRP is used to create a secure channel and system 110 provides digital key configuration data. This configuration information may include various fields, e.g., indicating what type of transactions are allowed, system metadata, start date, expiration date, public keys, a system identifier, etc. In some embodiments, system 110 is configured to reject pairing unless the mobile device properly attests that the digital key was created according to the configuration data.
Regarding claims 4 and 17, Matthias teaches, wherein the code is further executable by the processor to invalidate the at least one of the key pair and the calculated digital fingerprint for the apparatus in response to expiration of the validity time period(since keys and certificate created are ephemeral they are invalidated after expiration, ¶69).
[0069] In the illustrated embodiment, the key pair includes an ephemeral public key system.ePK and an ephemeral secret key system.eSK. The keys may be “ephemeral” in the sense that they are limited-use, e.g., valid only for a certain number of uses (including embodiments in which they are valid for only a single use) or valid for a certain time interval. Ephemeral keys may be deleted at the end of each transaction. Because ephemeral keys are invalid after expiration, this may prevent the keys from being re-used by an unauthorized individual if they are somehow intercepted.
Regarding claim 8, Matthias teaches wherein, in response to a request to initiate the secure pairing process with the second computing device, the code is further executable by the processor to generate the key pair for the apparatus, the key pair comprising a public key and a private key.
[0068] In the illustrated embodiment, at 306 system 110 verifies the authentication information and, in response, generates an ephemeral key pair. In the illustrated embodiment, system 110 switches to a “pairing in progress state” at this point. Note that in other embodiments, other states may be used and the states may be entered or exited at different points than shown.
[0069] In the illustrated embodiment, the key pair includes an ephemeral public key system.ePK and an ephemeral secret key system.eSK. The keys may be “ephemeral” in the sense that they are limited-use, e.g., valid only for a certain number of uses (including embodiments in which they are valid for only a single use) or valid for a certain time interval. Ephemeral keys may be deleted at the end of each transaction. Because ephemeral keys are invalid after expiration, this may prevent the keys from being re-used by an unauthorized individual if they are somehow intercepted.
Regarding claim 9, Matthias teaches wherein the code is further executable by the processor to transmit the public key for the apparatus to the second computing device.
[0071] In response to initiation of the pairing procedure, at 312 AP 136 also generates an ephemeral key pair phone.ePK and phone.eSK, in the illustrated embodiment. In the illustrated embodiment, system 110 and AP 135 then exchange their respective generated ephemeral public keys, system.ePK and phone.ePK at 314 and 316. Each device then derives a shared secret based on the exchanged public keys and their respective secret keys at 318. As discussed above, ECDH may be used to derive the shared secret. At this point in the process, in the illustrated embodiment, an unauthenticated secure channel has been established between the system 110 and the mobile device 130 using ephemeral keys. In other embodiments, other techniques may be used to establish a shared secret or key. The disclosed techniques for obtaining a shared secret are disclosed for purposes of illustration, but are not intended to limit the scope of the present disclosure.
Regarding claim 10, Matthias teaches wherein the code is further executable by the processor to calculate a shared secret seed using a key agreement protocol between the apparatus and the second computing device, the key agreement protocol comprising an elliptic curve cryptography protocol.
[0084] In the illustrated embodiment at 402, system 110 starts communication with AP 136. In some embodiments, this includes sending polling messages (e.g., NFC anti-collision enhanced contactless polling (ECP) messages). In other embodiments, other communication initiation techniques may be used. In response, AP 136 generates an ephemeral key pair phone.eSK and phone.ePK, in the illustrated embodiment at 404 (although other processing elements such as SE 134 may generate the ephemeral key pair in other embodiments). Examples of key pairs include elliptic curve cryptography (ECC) pairs, pairs generated using AES encryption, etc. In the illustrated embodiment, AP 136 sends this key pair and channel negotiation options to system 110 at 406. In some embodiments, in response to determining that it is within communication distance with system 110, mobile device 130 may automatically prompt the user for input of one or more commands for system 110.
[0190] At 1022, in the illustrated embodiment, mobile device 130 generates a derived shared secret, generates a signature, and encrypts the signature based on the derived shared secret. In some embodiments, this includes to generate KAEseed=KDF(DH(system.ePK, phone.eSK), system.ePK|phone.ePK|system.PK). In this example, the Diffie Hellman function DH is one example of a key exchange function used to generate a shared secret and the key derivation function KDF generates a derived shared secret based on the output of the key exchange function, and the public keys system.ePK, phone.ePK, and system.PK. In some embodiments, mobile device 130 also defines a diversifier=transaction.identifier|phone.ePK|system.ePK|systemIdentifier|system.PK. In some embodiments, mobile device 130 computes KAEe1:KAEm1:IVe1=KDF(KAEseed, diversifier|“phone to system”) and computes KAEe2:KAEm2:IVe2=KDF(KAEseed, diversifier|“system to phone”). These derived symmetric keys may be used to encrypt information identifying the phone and/or confidential payloads, which may increase security of such information.
Regarding claim 11, Matthias teaches wherein the code is further executable by the processor to calculate a second key based on identifiers for the apparatus and the second computing device(symmetric key is created based on shared secret of the system and mobile public keys and other device information, ¶s159,160,190).
[0159] systemIdentifier, in some embodiments, is a unique identifier of the system. For NFC transactions it may be protected by the reach of the RF field. For BT transactions, it may rely on the privacy protection of the BT channel. On device side it may be used to determine the long term public key of the system.
[0160] phoneIdentifier, in some embodiments, is a unique identifier of the device. In some embodiments, it is protected for privacy during the transaction by sending it in a secure channel after the phone has verified the system identity. It may be used on system side to select the device public key to verify the signature transaction.Type reader-determined value that indicates which flow shall be taken, fast or standard/full.
[0190] At 1022, in the illustrated embodiment, mobile device 130 generates a derived shared secret, generates a signature, and encrypts the signature based on the derived shared secret. In some embodiments, this includes to generate KAEseed=KDF(DH(system.ePK, phone.eSK), system.ePK|phone.ePK|system.PK). In this example, the Diffie Hellman function DH is one example of a key exchange function used to generate a shared secret and the key derivation function KDF generates a derived shared secret based on the output of the key exchange function, and the public keys system.ePK, phone.ePK, and system.PK. In some embodiments, mobile device 130 also defines a diversifier=transaction.identifier|phone.ePK|system.ePK|systemIdentifier|system.PK. In some embodiments, mobile device 130 computes KAEe1:KAEm1:IVe1=KDF(KAEseed, diversifier|“phone to system”) and computes KAEe2:KAEm2:IVe2=KDF(KAEseed, diversifier|“system to phone”). These derived symmetric keys may be used to encrypt information identifying the phone and/or confidential payloads, which may increase security of such information.
Regarding claim 12, Matthias teaches wherein the code is further executable by the processor to generate the digital certificate using a key generated using elliptic curve cryptography (“ECC”) based on the second key and a dynamically determined generator ECC point.
[0084] In the illustrated embodiment at 402, system 110 starts communication with AP 136. In some embodiments, this includes sending polling messages (e.g., NFC anti-collision enhanced contactless polling (ECP) messages). In other embodiments, other communication initiation techniques may be used. In response, AP 136 generates an ephemeral key pair phone.eSK and phone.ePK, in the illustrated embodiment at 404 (although other processing elements such as SE 134 may generate the ephemeral key pair in other embodiments). Examples of key pairs include elliptic curve cryptography (ECC) pairs, pairs generated using AES encryption, etc. In the illustrated embodiment, AP 136 sends this key pair and channel negotiation options to system 110 at 406. In some embodiments, in response to determining that it is within communication distance with system 110, mobile device 130 may automatically prompt the user for input of one or more commands for system 110.
[0201] In some embodiments, various modification may be made to the transactions of FIG. 10 to increase performance. For example, compact or compressed form may be used for ECC points, e.g., to reduce public key sizes. In some embodiments, a minimum amount of data may be transferred that is needed to reconstruct system.eCert (e.g., rather than the fill eCert). In some embodiments, data may be prefetched, such as the ephemeral keys, systemIdentifier, transaction.ID, etc. Further, selection of an efficient EC curve may also improve performance.
Regarding claim 13, Matthias teaches wherein the secure pairing process comprises a mutual transport layer security (“mTLS”) protocol(mutual authentication performed based on TLS protocol, or on other words mutual TLS or mTLS where both client and server, or mobile device and system exchange certificates and digital signature and validate each other as part of creating a secure connection, ¶s118,243)
[0118] At 710, in the illustrated embodiment, in response to receiving a first request to perform a pairing operation with a system, a mobile device establishes a first shared encryption key with the system. This may include establishing an ephemeral key pair and deriving a shared secret based on the ephemeral key pair. Deriving the shared secret may use ECDH or some other asymmetric encryption technique. The request to perform the pairing operation may be received from the system or from a user (e.g., via an input component). Note that various embodiments are described herein with reference to a vehicle and a mobile phone phone. These devices are included for purposes of illustration but are not intended to limit the scope of the present disclosure. In various embodiments, the disclosed techniques may be used for mutual authentication between two or more of various types of devices. For example, similar techniques may be used to authenticate devices with paired wearable devices, distributed sensors, interne of things devices, etc.
[0243]…The secure session may use standard protocol like TLS such that the device is able to authenticate the server. Once this session is established, the device may use the secure element to sign challenges provided by the system and commands to be executed by the system. The system manufacturer's server, acting as a proxy, may check packet formatting and signatures are correct before transmitting requests to the system. Firewall-type protection against denial of service or ill-formatted packet may also be handled by the system manufacturer's server. In some embodiments, TLS server authentication might be upgraded with client authentication after the device successfully signs a server challenge with a valid key, which may help filter DOS attacks at the cost of increased complexity.
Claims 5 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Mathias/Vass/Hartsock as applied to claims 4 and 17 above, and further in view of Matthias et al US 2017/0359314 hereafter Matthias314.
Regarding claim 5 and 18. Mathias/Vass/Hartsock teach expiring certificates and ephemeral keys but does not specifically teach wherein invalidation of the at least one of the key pair and the calculated digital fingerprint for the apparatus disconnects the secure network connection with the second computing device. Mathias314 in the same field of endeavor as the invention teaches a system for secure connection and data transfer between devices. Mathias314 teaches wherein invalidation of the at least one of the key pair and the calculated digital fingerprint for the apparatus disconnects the secure network connection with the second computing device(either device can end session i.e. disconnect by invalidating session key, ¶62) .
[0062] In some embodiments, communication with a given accessory can be limited to authorized controllers. The protocol can specify one or more mechanisms (including mechanisms referred to herein as “pair setup” and “pair add”) for establishing a “pairing” between a controller and a given accessory under circumstances that provide a high degree of confidence that the user intends for the controller to be able to control the accessory. Pair setup can include an out-of-band information exchange (e.g., the user can enter a numerical or alphanumeric PIN or passcode provided by the accessory into an interface provided by the controller) to establish a shared secret. This shared secret can be used to support secure exchange of “long-term” public keys between the controller and the accessory, and each device can store the long-term public key received from the other, so that an established pairing can be persistent. After a pairing is established, the paired controller is considered authorized, and thereafter, the controller and accessory can go in and out of communication as desired without losing the established pairing. When a controller attempts to communicate with or control an accessory, a “pair verify” process can first be performed to verify that an established pairing exists (as would be the case, e.g., where the controller previously completed pair setup with the accessory). The pair verify process can include each device demonstrating that it is in possession of a long-term private key corresponding to the long-term public key that was exchanged during pair setup and can further include establishing a new shared secret or session key to encrypt all communications during a “pair-verified” session, (also referred to herein as a verified session). During a pair-verified session, a controller that has appropriate privileges can perform a “pair add” process to establish another pairing with the accessory on behalf of another controller. Either device can end a pair-verified session at any time simply by destroying or invalidating its copy of the session key.
It would have been obvious to a person of ordinary skill in the art at the time of the effective filing of the instant application to modify Matthias/Vass/Hartsock with ending a connection by invalidating the session key as taught by Mathias314. The reason for this modification would be to provide a method of disconnecting a session between devices and protect against reuse of old keys.
Claims 6 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Matthias/Vass/Hartsock as applied to claims 1 and 14 above, and further in view of Monica US 2013/0182845.
Regarding claim 6 and 19, Matthias/Vass/Hartsock teach that the certificates/keys and signatures expire since they are based on ephemeral key generation bus does not specifically teach wherein the code is further executable by the processor to invalidate the at least one of the key pair and the calculated digital fingerprint for the apparatus in response to disconnection of the secure network connection with the second computing device. Monica in the same field of endeavor as the invention teaches a system for securing device to device connection for facilitating financial transactions. Monica teaches wherein the code is further executable by the processor to invalidate the at least one of the key pair and the calculated digital fingerprint for the apparatus in response to disconnection of the secure network connection with the second computing device(disconnection from between device and device acting a hotspot causes expiring of the keys, ¶s7,9).
[0007] Implementations may include one or more of the following features. Sending the request to the server may include sending a geographic location, current timestamp, a random number, or unique identification of the first mobile computing device. Authenticating the first mobile computing device with the server may include authenticating by the first mobile computing device logging into the server. A list of mobile computing devices connected to the Wi Fi hot spot may be received in the first mobile computing device. The session key may expire after a predetermined amount of time. The session key may expire when a mobile device connected to the Wi Fi hot spot is disconnected. The mobile computing devices and Wi Fi hot spot are in a vehicle or in the same business establishment, e.g., a restaurant. The trusted certificate may be a Transport Layer Security (TLS) certificate.
[0009] Implementations may include one or more of the following features. Verifying that the first mobile computing device is trusted may include determining the first mobile computing device has established a session with the server. After verifying that the second mobile computing device is trusted, the second mobile computing device may join the session. Verifying that the second mobile computing device is trusted may include determining the distance between the first mobile computing device and the second mobile computing device is within a predetermined distance. Verifying that the second mobile computing device is trusted may include determining a first unique identification of the first mobile computing device exists in a database. The trusted certificate may be a TLS certificate. The public or private key may expire after a predetermined amount of time. The public or private key may expire when the first mobile computing device or the second mobile computing device disconnect from the Wi Fi hot spot. The first request may include first metadata indicating a location, a timestamp, a random number, or a unique identification, and the second request may include second metadata matching the first metadata.
It would have been obvious to a person of ordinary skill in the art at the time of the effective filing of the instant application to modify Matthias/Vass/Hartsock with ending expire/invalidate the key upon ending the connection/session as taught by Monica. The reason for this modification would be to provide a method of disconnecting a session between devices and protect against reuse of old keys.
Claims 7 is rejected under 35 U.S.C. 103 as being unpatentable over Mathias/Vass/Hartsock as applied to claim and further in view of obvious modification by one or ordinary skill based on the teaching of Mathias.
Regarding claim 7, Matthias/Vass teaches wherein the secure pairing process is between a first plugin executing on the apparatus
[0056] Applets 226, in one embodiment, are executable to perform enrollment of mobile device 130 and authentication with a reader. With respect to enrollment, applets 226 may be executable to generate public-key pairs and obtain corresponding certificates, which may be stored in memory 224 as public-key information 228.
Matthias teaches a plugin for the apparatus/mobile device but does not specifically teach the software that performs key generation and secure connection protocol is performed using a plug in. Thus, Matthias does not specifically teach a second plugin executing on the second computing device. A person of ordinary skill in the art having an understanding of the benefits of software application implemented as installable applets such as the mobile device applets(¶56 Matthias) of Matthias would be motivated to further modify the system side key generation and secure connection software as a installable applet. The reason for such a modification would be to implement a secure connection software that is easily updateable with application that can perform new protocols and algorithms for secure connection and key generation.
Applicant Remarks
The applicant arguments that the cited references do not teach the claims as amended to include:” wherein the regenerated digital certificate is a self-signed, one time user certificate derived from the shared cryptographic seed and is valid for the subsequent communication session and differs from previously generated certificates”, has been considered but found unpersuasive. The examiner contends that Vass teaches certificate generation mechanism that performs a ratcheting mechanism and where the platform associated with the device generates acts as their own certificate authority. Such a combination teaches a self-signed certificates that are one-time use and where the certificate for the subsequent session is based on the key from the prior session, this is the definition of ratcheting keys. Thus the examiner contends that Matthias in view of Vass teaches claims 1, 14 and 20 as amended.
Furthermore, assuming arguendo that the combination of Matthias in view of Vass does not teach a certificate is a self-signed, one time user certificate derived from the shared cryptographic seed and is valid for the subsequent communication session, such limitation would be obvious in further view of Hartsock as present in the additional rejection above.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Tom Y. Chang whose telephone number is 571-270-5938. The examiner can normally be reached on Monday-Friday from 9am to 5pm.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Emmanuel Moise, can be reached on (571)272-3865. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from Patent Center. Status information for published applications may be obtained from Patent Center. Status information for unpublished applications is available through Patent Center for authorized users only. Should you have questions about access to Patent Center, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) Form at https://www.uspto.gov/patents/uspto-automated- interview-request-air-form.
/TOM Y CHANG/
Primary Examiner, Art Unit 2455