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 . In communications filed on 01/05/2026. Claim 1 is amended. Claims 1-30 are pending in this examination.
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status. This examination is in response to US Patent Application No. 18/280,558.
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission has been entered.
Examiner Note
Claim 12 describes “the second block” as: wherein the second block is implemented wholly in hardware and comprises a programmable logic device, PLD, a field programmable gate array, FPGA, and/or an application specific integrated circuit, ASIC, and/or the second block does not comprise a Turing machine.
Claim Objections
Claim 28 is objected to because of the following reason: it is unclear if this claim is an independent claim or dependent claim , if it is an independent claim , it needs to be written in independent claim format which includes all the limitations of the claim 1.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claim 30 is rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter. Claim 30 recites that “a computer- readable medium”. the computer- readable medium has been described in the specification as: The computer- readable medium may be a transitory computer-readable medium such as a signal, wherein the instructions are included in the signal. Broadly interpreted in light of the specification “machine readable storage media” would suggest to one ordinary skill in the art signals or other forms of propagation and transmission media that fails to be statutory. Therefore, claim 30 is directed to non-statutory subject matter. Examiner respectfully suggests amending the claim to include "non-transitory medium," A computer readable device storing”,” medium which is not a signal storing”, “An amendment to the spec defining the medium is not a signal",” An amendment to the spec defining the medium is a form of memory devices", “A disavowal statement and an amendment to the spec stating the medium is not a signal” or amending the specification to include “not signal” to make the claim statutory under 35 U.S.C. 101.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
Claims rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
The independent claims 1, 29, and 30 recite the limitation "conditional", which renders the claim indefinite because the language does not define a certainty and metes and bounds of the claim are unascertainable. Moreover, the term " conditional" is not defined by the claim, and the specification does not provide enough description.
Claims 2-28 do not cure the deficiency of claim 1 and are rejected under 35 USC 112, 2nd paragraph, for their dependency upon claim 1.
CLAIM INTERPRETATION
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) is/are: “first block is configured to…” in claim 15.
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claim 15 is rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor, or for pre-AIA the applicant regards as the invention.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) are: “first block is configured to…” in claim 15.
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
Claims limitation “first block is configured to…” in claim 15 invokes 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. However, the written description fails to disclose the corresponding structure, material, or acts for performing the entire claimed function and to clearly link the structure, material, or acts to the function. Therefore, the claim is indefinite and is rejected under 35 U.S.C. 112(b) or pre-AIA 35 U.S.C. 112, second paragraph.
Applicant may:
(a) Amend the claim so that the claim limitation will no longer be interpreted as a limitation under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph;
(b) Amend the written description of the specification such that it expressly recites what structure, material, or acts perform the entire claimed function, without introducing any new matter (35 U.S.C. 132(a)); or
(c) Amend the written description of the specification such that it clearly links the structure, material, or acts disclosed therein to the function recited in the claim, without introducing any new matter (35 U.S.C. 132(a)).
If applicant is of the opinion that the written description of the specification already implicitly or inherently discloses the corresponding structure, material, or acts and clearly links them to the function so that one of ordinary skill in the art would recognize what structure, material, or acts perform the claimed function, applicant should clarify the record by either:
(a) Amending the written description of the specification such that it expressly recites the corresponding structure, material, or acts for performing the claimed function and clearly links or associates the structure, material, or acts to the claimed function, without introducing any new matter (35 U.S.C. 132(a)); or
(b) Stating on the record what the corresponding structure, material, or acts, which are implicitly or inherently set forth in the written description of the specification, perform the claimed function. For more information, see 37 CFR 1.75(d) and MPEP §§ 608.01(o) and 2181.
Response to Arguments
Applicant’s arguments with respect to claims 1, 29, and 30 for limitation: determine the shared secret between the second block and the second computer system, wherein the shared secret is not provided to the first block have been considered but are moot because the arguments do not apply to any of the references being used in the current rejection.
Applicant's arguments filed 01/05/2026 have been fully considered but they are not persuasive:
Applicant submits on pages 10-14 of remarks filed on 01/05/2026 regarding claim 1 that Kancharla cannot anticipate Claim 1 of the present application at least because Kancharla fails to teach, disclose, or suggest, either expressly or inherently, each and every feature of Claim 1.
a) provide a key to the first block for transmittal to the second computer system as a handshaking message for use in establishing a shared secret between the second block and the second computer system
a1) determine the shared secret between the second block and the second computer system, wherein the shared secret is not provided to the first block
b) conditional on the data received from the first block indicating that the key provided from the second block to the first block was sent to the second computer system as a key for use in establishing the shared secret, generate authentication data ...
c) exchange further encrypted messages with the second computer system via the first block under the cryptographically secure connection.
Examiner respectfully disagrees with applicant argument for claim 1 filed on 01/05/2026 on pages 12-14 of remarks.
While Kancharla discloses:
a) provide a key to the first block for transmittal to the second computer system as a handshaking message for use in establishing a shared secret between the second block and the second computer system
[ see FIG. 1, ¶18, In some embodiments, the server 108 is configured to communicate securely with a client device 110 requesting connection and service by the server 108 via Elliptic curve Diffie-Hellman (ECDH) protocol. Here, the client device 110 can be a computing device, a communication device, a storage device, or any electronic device. ECDH is an anonymous key agreement protocol using elliptic curve cryptography that allows two parties (server 108 and client 110), each having an elliptic curve public-private key pair, to establish a shared pre-master secret (PMS) over an insecure channel. This shared PMS may be used either as an encryption/decryption key directly, or to derive another key which can then be used to encrypt subsequent PFS communications between the server and the client device using a symmetric key cipher], and [¶20, In some embodiments, the HSM 102(equated to first block) is configured to accept a plurality of parameters passed by the server 108(equated to second block) via the API calls for the ECDH key generation. Such input parameters passed by the server 104 include but are not limited to ECDH curve type, client 110 as identified by its network/IP address, the random number and the SSL session ID generated by the server 108, RSA and/or Elliptic Curve Digital Signature Algorithm (ECDSA) key handle for signature, and supporting access rights and/or authorization policy data as to which third parties can access the derived keying materials and the server's ECDH parameters/keys. Upon receiving the parameters, the HSM 102 is configured to select an ECDH private key/parameters for the server 108 suitable for the ECDH curve type, store the ECDH private key in its memory (e.g., RAM) in a HSM table along/in association with the access rights and/or authorization policy data with key_ID attribute set to the SSL_Session_ID provided as an index to the HSM table. Note that the HSM 102 is FIPS 140-2 compliant, which meets FIPS compliance requirements of the ECDH private keys of the server 108. The HSM 102 is then configured to compute ECDH public key/parameters and signature of the server 108 based on private parameters and the random number received. The HSM 102 is then configured to provide the calculated ECDH public parameters signed by the RSA/ECDSA signature or authentication key of the server 108 to the client device 110 in the form of a server hello message. Note that all of the public/private keys of the server 108 are ephemeral session keys that are only valid and used during the current ECDH session. The ephemeral keys will expire and be removed from the HSM table after the current ECDH session or timeout]; and
Examiner Note:
PNG
media_image1.png
550
734
media_image1.png
Greyscale
Furthermore, Campagna ( US2017/0310652) discloses [ see FIGs 2-4, and corresponding text for more detail, 056] FIG. 4 shows an illustrative environment 400 in which two clients establish a cryptographically protected communication session. The first client 302( equated to second block), second client 304( second computer system), and cryptography service 306( equated to first block) may be similar to those described above in accordance with FIGS. 1-3. In some embodiments, the first client 402 may have generated an ECDH key pair including a private key d.sub.A and public key Q.sub.A where the public key Q.sub.A has been distributed to the second client 404, perhaps in accordance with embodiments described above in FIG. 2. Likewise, the second client 404 may have generated a second ECDH key pair including a private key d.sub.B and a public key Q.sub.B where public key Q.sub.B has been distributed to the first client 402, perhaps in accordance with embodiments described in FIGS. 2-3].
Kancharla does not explicitly disclose; however, Campagna discloses :
a1) determine the shared secret between the second block and the second computer
system, wherein the shared secret is not provided to the first block
Campagna ( US2017/0310652) [¶23-¶24, 0023] In one example, two clients may use a partially trusted cryptography service to perform a key exchange…. After exchanging public keys, the first and second client can compute a shared secret—the first client computes the elliptic curve point multiplication of d.sub.AQ.sub.B and the second client computes the elliptic curve point multiplication of d.sub.BQ.sub.A. In an elliptic curve Diffie-Hellman key exchange, the two values are equal and may be used as a key or to generate a private key that may be used to establish a cryptographically protected communication session such as a TLS session. Once established, the first client and the second client may communicate via the cryptographically protected communication session with assurances that the cryptography service does not know the shared secret, and thus does not know the private key used in the TLS session. This provides greater security assurances because the cryptography service cannot participate in the cryptographically protected communication session. The clients are assured that the cryptography service cannot compute the shared secret and eavesdrop or perform a “man-in-the-middle” attack for cryptographically protected communication sessions generated in the manner described above. cryptographically protected communication sessions generated in the manner described above], and [¶¶56-58, FIG. 4 shows an illustrative environment 400 in which two clients establish a cryptographically protected communication session. The first client 302, second client 304, and cryptography service 306 may be similar to those described above in accordance with FIGS. 1-3. In some embodiments, the first client 402 may have generated an ECDH key pair including a private key d.sub.A and public key Q.sub.A where the public key Q.sub.A has been distributed to the second client 404, perhaps in accordance with embodiments described above in FIG. 2. Likewise, the second client 404 may have generated a second ECDH key pair including a private key d.sub.B and a public key Q.sub.B where public key Q.sub.B has been distributed to the first client 402, perhaps in accordance with embodiments described in FIGS. 2-3. In some embodiments, the first client 402 has a shared secret 406 that may be generated using at least d.sub.A and Q.sub.B and the second client 404 has a shared secret 408 that may be generated using at least d.sub.B and Q.sub.A. In embodiments using an elliptic curve Diffie-Hillman key agreement protocol, the shared secret may be calculated by both parties because d.sub.AQ.sub.B=d.sub.BQ.sub.A. A cryptographically protected communication session 410 may be established using the shared secret. In some embodiments, the cryptography service 406 may not have access to both private keys d.sub.A and d.sub.B and will not be able to access 412 the cryptographically protected communication session…FIG. 5 shows a diagram illustrating a handshake protocol between a first client 502, a second client 504, and cryptography service 506 in accordance with an embodiment. As part of the handshake protocol, the first client may generate 508 an ECDH key pair including a private key d.sub.A and a public key Q.sub.A. In some embodiments, the ECDH key pair may be pre-generated prior to the start of the handshake].
While Kancharla discloses:
b) conditional on the data received from the first block indicating that the key provided from the second block to the first block was sent to the second computer system as a key for use in establishing the shared secret, generate authentication data ...
[¶18, In some embodiments, the server 108(equated to second block) is configured to communicate securely with a client device 110 requesting connection and service by the server 108 via Elliptic curve Diffie-Hellman (ECDH) protocol. Here, the client device 110 can be a computing device, a communication device, a storage device, or any electronic device. ECDH is an anonymous key agreement protocol using elliptic curve cryptography that allows two parties (server 108 and client 110), each having an elliptic curve public-private key pair, to establish a shared pre-master secret (PMS) over an insecure channel. This shared PMS may be used either as an encryption/decryption key directly, or to derive another key which can then be used to encrypt subsequent Perfect Forward Secrecy (PFS) communications between the server and the client device using a symmetric key cipher], and [¶21, Upon receiving the server hello message from the HSM 102, the client 110 generates and provides its own ECDH public key/parameters to the server 108. After receiving the public key parameters from the server 108 is further configured to call APIs provided by the HSM 102 and pass the public key parameters to the HSM 102 to generate a pre-master secret (PMS) to be shared with the client 110 (and a third party as discussed below) during the session. Specifically, the HSM 102 is configured to accept key_ID (i.e., SSL_session_ID) and the client's ECDH public parameters from the server 108. The HSM 102 is then configured to compute the PMS for the server 108 as an ECDH value based on the public keys and parameters of the server and the client. The HSM 102 then stores the computed PMS in the HSM table with the key_ID/SSL_session_ID as its index. Finally, the HSM 102((equated to first block)) is configured to share the computed PMS with the client 110, wherein the PMS is used as the key or to generate a key for the ECDH session between the server 108 and the client 110], and [¶¶20, 29]; and
Furthermore, Campagna ( US2017/0310652) discloses [ see FIGs 2-4, and corresponding text for more detail, 056] FIG. 4 shows an illustrative environment 400 in which two clients establish a cryptographically protected communication session. The first client 302( equated to second block), second client 304( second computer system), and cryptography service 306( equated to first block) may be similar to those described above in accordance with FIGS. 1-3. In some embodiments, the first client 402 may have generated an ECDH key pair including a private key d.sub.A and public key Q.sub.A where the public key Q.sub.A has been distributed to the second client 404, perhaps in accordance with embodiments described above in FIG. 2. Likewise, the second client 404 may have generated a second ECDH key pair including a private key d.sub.B and a public key Q.sub.B where public key Q.sub.B has been distributed to the first client 402, perhaps in accordance with embodiments described in FIGS. 2-3.
While Kancharla discloses:
c) exchange further encrypted messages with the second computer system via the first block under the cryptographically secure connection.
[¶18, In some embodiments, the server 108 is configured to communicate securely with a client device 110 requesting connection and service by the server 108 via Elliptic curve Diffie-Hellman (ECDH) protocol. Here, the client device 110 can be a computing device, a communication device, a storage device, or any electronic device. ECDH is an anonymous key agreement protocol using elliptic curve cryptography that allows two parties (server 108 and client 110), each having an elliptic curve public-private key pair, to establish a shared pre-master secret (PMS) over an insecure channel. This shared PMS may be used either as an encryption/decryption key directly, or to derive another key which can then be used to encrypt subsequent Perfect Forward Secrecy (PFS) communications between the server and the client device using a symmetric key cipher], and [¶29, In the example of FIG. 3, the flowchart 300 starts at block 302, where one or more ephemeral public and private keys and/or parameters used for secured communication between a server running on a host and a client device intends to access the server during a current session are generated and stored on a hardware security module (HSM)…].
Furthermore, Campagna ( US2017/0310652) discloses [ see FIGs 2-4, and corresponding text for more detail, 056] FIG. 4 shows an illustrative environment 400 in which two clients establish a cryptographically protected communication session. The first client 302( equated to second block), second client 304( second computer system), and cryptography service 306( equated to first block) may be similar to those described above in accordance with FIGS. 1-3. In some embodiments, the first client 402 may have generated an ECDH key pair including a private key d.sub.A and public key Q.sub.A where the public key Q.sub.A has been distributed to the second client 404, perhaps in accordance with embodiments described above in FIG. 2. Likewise, the second client 404 may have generated a second ECDH key pair including a private key d.sub.B and a public key Q.sub.B where public key Q.sub.B has been distributed to the first client 402, perhaps in accordance with embodiments described in FIGS. 2-3.
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 of this title, 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.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-5, 8, and 11-30 are rejected under 35 U.S.C. 103 as being unpatentable over US Patent No. ((US2018/0062854) issued to Kancharla , and further in view of US Patent No. (US2017/0310652) issued to Campagna.
Regarding claim 1, Kancharla discloses a first computer system comprising a first block and a second block [¶17, see FIG. 1, the HSM 102 (equated to first block) is connected/coupled to the host 104 running the server 108 (equated to second block) via a PCIe bus in order to interact with and to offload the ephemeral keys from the VMs 108 in a secure manner]; and
the second block configured to perform handshake operations in combination the first block for establishing a cryptographically secure connection between the first computer system and a second computer system, the second block configured to
[0019] During the handshake to establish a secured ECDH communication session between the server 108 and the client 110, the client 110 may initiate a client hello message over a non-secured communication channel requesting connection to the server 108 (equated to second block). After receiving the client hello message, the server 108 is configured to generate a unique random number and an ID for an SSL session with the client 110. Here, the session ID is a unique ID derived from the unique random number. The server 108 is further configured to call APIs provided by the HSM 102(equated to first block) to generate ECDH key/parameters used by the server 108 for the ECDH session], and [ see FIG 1., and ¶¶20-21]: and
While Kancharla discloses:
provide a key to the first block for transmittal to the second computer system as a handshaking message for use in establishing a shared secret between the second block and the second computer system [ see FIG. 1, ¶18, In some embodiments, the server 108 is configured to communicate securely with a client device 110 requesting connection and service by the server 108 via Elliptic curve Diffie-Hellman (ECDH) protocol. Here, the client device 110 can be a computing device, a communication device, a storage device, or any electronic device. ECDH is an anonymous key agreement protocol using elliptic curve cryptography that allows two parties (server 108 and client 110), each having an elliptic curve public-private key pair, to establish a shared pre-master secret (PMS) over an insecure channel. This shared PMS may be used either as an encryption/decryption key directly, or to derive another key which can then be used to encrypt subsequent PFS communications between the server and the client device using a symmetric key cipher] , and [¶20, In some embodiments, the HSM 102(equated to first block) is configured to accept a plurality of parameters passed by the server 108(equated to second block) via the API calls for the ECDH key generation. Such input parameters passed by the server 104 include but are not limited to ECDH curve type, client 110 as identified by its network/IP address, the random number and the SSL session ID generated by the server 108, RSA and/or Elliptic Curve Digital Signature Algorithm (ECDSA) key handle for signature, and supporting access rights and/or authorization policy data as to which third parties can access the derived keying materials and the server's ECDH parameters/keys. Upon receiving the parameters, the HSM 102 is configured to select an ECDH private key/parameters for the server 108 suitable for the ECDH curve type, store the ECDH private key in its memory (e.g., RAM) in a HSM table along/in association with the access rights and/or authorization policy data with key_ID attribute set to the SSL_Session_ID provided as an index to the HSM table. Note that the HSM 102 is FIPS 140-2 compliant, which meets FIPS compliance requirements of the ECDH private keys of the server 108. The HSM 102 is then configured to compute ECDH public key/parameters and signature of the server 108 based on private parameters and the random number received. The HSM 102 is then configured to provide the calculated ECDH public parameters signed by the RSA/ECDSA signature or authentication key of the server 108 to the client device 110 in the form of a server hello message. Note that all of the public/private keys of the server 108 are ephemeral session keys that are only valid and used during the current ECDH session. The ephemeral keys will expire and be removed from the HSM table after the current ECDH session or timeout].
Furthermore, Campagna ( US2017/0310652) discloses [ see FIGs 2-4, and corresponding text for more detail, 056] FIG. 4 shows an illustrative environment 400 in which two clients establish a cryptographically protected communication session. The first client 302( equated to second block), second client 304( second computer system), and cryptography service 306( equated to first block) may be similar to those described above in accordance with FIGS. 1-3. In some embodiments, the first client 402 may have generated an ECDH key pair including a private key d.sub.A and public key Q.sub.A where the public key Q.sub.A has been distributed to the second client 404, perhaps in accordance with embodiments described above in FIG. 2. Likewise, the second client 404 may have generated a second ECDH key pair including a private key d.sub.B and a public key Q.sub.B where public key Q.sub.B has been distributed to the first client 402, perhaps in accordance with embodiments described in FIGS. 2-3].
While Kancharla discloses:
receive data from the first block, the data purportedly representative of handshaking messages exchanged between the first block and the second computer system [¶¶20-21, Upon receiving the server hello message from the HSM 102, the client 110 generates and provides its own ECDH public key/parameters to the server 108. After receiving the public key parameters from the server 108 is further configured to call APIs provided by the HSM 102 and pass the public key parameters to the HSM 102 to generate a pre-master secret (PMS) to be shared with the client 110 (and a third party as discussed below) during the session. Specifically, the HSM 102 is configured to accept key_ID (i.e., SSL_session_ID) and the client's ECDH public parameters from the server 108. The HSM 102 is then configured to compute the PMS for the server 108 as an ECDH value based on the public keys and parameters of the server and the client. The HSM 102 then stores the computed PMS in the HSM table with the key_ID/SSL_session_ID as its index. Finally, the HSM 102 is configured to share the computed PMS with the client 110, wherein the PMS is used as the key or to generate a key for the ECDH session between the server 108 and the client 110].
Furthermore, Campagna ( US2017/0310652) discloses [ see FIGs 2-4, and corresponding text for more detail, 056] FIG. 4 shows an illustrative environment 400 in which two clients establish a cryptographically protected communication session. The first client 302( equated to second block), second client 304( second computer system), and cryptography service 306( equated to first block) may be similar to those described above in accordance with FIGS. 1-3. In some embodiments, the first client 402 may have generated an ECDH key pair including a private key d.sub.A and public key Q.sub.A where the public key Q.sub.A has been distributed to the second client 404, perhaps in accordance with embodiments described above in FIG. 2. Likewise, the second client 404 may have generated a second ECDH key pair including a private key d.sub.B and a public key Q.sub.B where public key Q.sub.B has been distributed to the first client 402, perhaps in accordance with embodiments described in FIGS. 2-3].
While Kancharla discloses:
conditional on the data received from the first block indicating that the key provided from the second block to the first block was sent to the second computer system as a key for use in establishing the shared secret, generate authentication data by performing a cryptographic authentication operation based on the data received from the first block, wherein the authentication data is provided by the second block to the first block for transmittal to the second computer system [¶18, In some embodiments, the server 108(equated to second block) is configured to communicate securely with a client device 110 requesting connection and service by the server 108 via Elliptic curve Diffie-Hellman (ECDH) protocol. Here, the client device 110 can be a computing device, a communication device, a storage device, or any electronic device. ECDH is an anonymous key agreement protocol using elliptic curve cryptography that allows two parties (server 108 and client 110), each having an elliptic curve public-private key pair, to establish a shared pre-master secret (PMS) over an insecure channel. This shared PMS may be used either as an encryption/decryption key directly, or to derive another key which can then be used to encrypt subsequent Perfect Forward Secrecy (PFS) communications between the server and the client device using a symmetric key cipher], and [¶21, Upon receiving the server hello message from the HSM 102, the client 110 generates and provides its own ECDH public key/parameters to the server 108. After receiving the public key parameters from the server 108 is further configured to call APIs provided by the HSM 102 and pass the public key parameters to the HSM 102 to generate a pre-master secret (PMS) to be shared with the client 110 (and a third party as discussed below) during the session. Specifically, the HSM 102 is configured to accept key_ID (i.e., SSL_session_ID) and the client's ECDH public parameters from the server 108. The HSM 102 is then configured to compute the PMS for the server 108 as an ECDH value based on the public keys and parameters of the server and the client. The HSM 102 then stores the computed PMS in the HSM table with the key_ID/SSL_session_ID as its index. Finally, the HSM 102((equated to first block)) is configured to share the computed PMS with the client 110, wherein the PMS is used as the key or to generate a key for the ECDH session between the server 108 and the client 110], and [¶¶20, 29].
Furthermore, Campagna ( US2017/0310652) discloses [ see FIGs 2-4, and corresponding text for more detail, 056] FIG. 4 shows an illustrative environment 400 in which two clients establish a cryptographically protected communication session. The first client 302( equated to second block), second client 304( second computer system), and cryptography service 306( equated to first block) may be similar to those described above in accordance with FIGS. 1-3. In some embodiments, the first client 402 may have generated an ECDH key pair including a private key d.sub.A and public key Q.sub.A where the public key Q.sub.A has been distributed to the second client 404, perhaps in accordance with embodiments described above in FIG. 2. Likewise, the second client 404 may have generated a second ECDH key pair including a private key d.sub.B and a public key Q.sub.B where public key Q.sub.B has been distributed to the first client 402, perhaps in accordance with embodiments described in FIGS. 2-3].
and exchange further encrypted messages with the second computer system via the first block under the cryptographically secure connection, wherein the further encrypted messages sent to the second computer system are encrypted by the second block and the further encrypted messages received from the second computer system are decrypted by the second block, the encryption and decryption performed using one or more session keys derived from the shared secret [¶3, In cryptography, Perfect Forward Secrecy (PFS) is a function of a key-exchange protocol, which results in the generation of a shared secret (e.g., pre-master secret or PMS) that may be used as an input to the key used to encrypt/decrypt an Secure Sockets Layer (SSL) session for secured communication between two parties (e.g., a web server and a browser of a client device). Key-exchange protocols that provide PFS are ephemeral because they use a temporary public/private key pair to generate the shared secret…,, PFS protects past sessions against future compromises of secret keys since encrypted communication sessions recorded in the past cannot be retrieved and decrypted should long-term secret keys or passwords be compromised in the future, even if the adversary actively interfered], and [¶18, In some embodiments, the server 108 is configured to communicate securely with a client device 110 requesting connection and service by the server 108 via Elliptic curve Diffie-Hellman (ECDH) protocol. Here, the client device 110 can be a computing device, a communication device, a storage device, or any electronic device. ECDH is an anonymous key agreement protocol using elliptic curve cryptography that allows two parties (server 108 and client 110), each having an elliptic curve public-private key pair, to establish a shared pre-master secret (PMS) over an insecure channel. This shared PMS may be used either as an encryption/decryption key directly, or to derive another key which can then be used to encrypt subsequent Perfect Forward Secrecy (PFS) communications between the server and the client device using a symmetric key cipher], and [¶20, Note that all of the public/private keys of the server 108 are ephemeral session keys that are only valid and used during the current ECDH session. The ephemeral keys will expire and be removed from the HSM table after the current ECDH session or timeout].
Kancharla does not explicitly disclose; however, Campagna discloses :
a1) determine the shared secret between the second block and the second computer
system, wherein the shared secret is not provided to the first block; wherein the one or more session keys are not shared with the first block
Campagna ( US2017/0310652)[¶¶23-24, 0023] In one example, two clients may use a partially trusted cryptography service to perform a key exchange…. After exchanging public keys, the first and second client can compute a shared secret—the first client computes the elliptic curve point multiplication of d.sub.AQ.sub.B and the second client computes the elliptic curve point multiplication of d.sub.BQ.sub.A. In an elliptic curve Diffie-Hellman key exchange, the two values are equal and may be used as a key or to generate a private key that may be used to establish a cryptographically protected communication session such as a TLS session. Once established, the first client and the second client may communicate via the cryptographically protected communication session with assurances that the cryptography service does not know the shared secret, and thus does not know the private key used in the TLS session. This provides greater security assurances because the cryptography service cannot participate in the cryptographically protected communication session. The clients are assured that the cryptography service cannot compute the shared secret and eavesdrop or perform a “man-in-the-middle” attack for cryptographically protected communication sessions generated in the manner described above. cryptographically protected communication sessions generated in the manner described above], and [¶¶56-58, FIG. 4 shows an illustrative environment 400 in which two clients establish a cryptographically protected communication session. The first client 302, second client 304, and cryptography service 306 may be similar to those described above in accordance with FIGS. 1-3. In some embodiments, the first client 402 may have generated an ECDH key pair including a private key d.sub.A and public key Q.sub.A where the public key Q.sub.A has been distributed to the second client 404, perhaps in accordance with embodiments described above in FIG. 2. Likewise, the second client 404 may have generated a second ECDH key pair including a private key d.sub.B and a public key Q.sub.B where public key Q.sub.B has been distributed to the first client 402, perhaps in accordance with embodiments described in FIGS. 2-3. In some embodiments, the first client 402 has a shared secret 406 that may be generated using at least d.sub.A and Q.sub.B and the second client 404 has a shared secret 408 that may be generated using at least d.sub.B and Q.sub.A. In embodiments using an elliptic curve Diffie-Hillman key agreement protocol, the shared secret may be calculated by both parties because d.sub.AQ.sub.B=d.sub.BQ.sub.A. A cryptographically protected communication session 410 may be established using the shared secret. In some embodiments, the cryptography service 406 may not have access to both private keys d.sub.A and d.sub.B and will not be able to access 412 the cryptographically protected communication session…FIG. 5 shows a diagram illustrating a handshake protocol between a first client 502, a second client 504, and cryptography service 506 in accordance with an embodiment. As part of the handshake protocol, the first client may generate 508 an ECDH key pair including a private key d.sub.A and a public key Q.sub.A. In some embodiments, the ECDH key pair may be pre-generated prior to the start of the handshake].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of Kancharla by incorporating “implementing elliptic curve Diffie-Hellman key exchange to compute a shared secret for secure communication”, as taught by Campagna. One could have been motivated to do so in order to assure the clients that the cryptography service cannot compute the shared secret and eavesdrop or perform a “man-in-the-middle” attack for cryptographically protected communication sessions [ Campagna, ¶24].
Regarding claim 2, Kancharla does not explicitly disclose, however, Campagna discloses, wherein the key provided to the first block for transmittal to the second computer system for use in establishing a shared secret is a public key associated with a private key, wherein the private key is not shared with the first block. [ see FIGS 2-3, and corresponding text for more detail, [¶49, The message 210 may be generated by the first client 202 and includes at least the sender's identity and the public key. The message may be used to bind the sender's identity with the public key by attesting that the public key is associated to the sender and that the sender has possession of the corresponding private key. A binding in this context may refer to an association between a cryptographic public key and a client or entity that has access to the corresponding cryptographic private key].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of Kancharla by incorporating “implementing elliptic curve Diffie-Hellman key exchange to compute a shared secret for secure communication”, as taught by Campagna. One could have been motivated to do so in order to assure the clients that the cryptography service cannot compute the shared secret and eavesdrop or perform a “man-in-the-middle” attack for cryptographically protected communication sessions [ Campagna, ¶24].
Regarding claim 3, Kancharla discloses, wherein the public key and private key are temporary public and private keys generated at the start of connection process.
[¶3, In cryptography, Perfect Forward Secrecy (PFS) is a function of a key-exchange protocol, which results in the generation of a shared secret (e.g., pre-master secret or PMS) that may be used as an input to the key used to encrypt/decrypt an Secure Sockets Layer (SSL) session for secured communication between two parties (e.g., a web server and a browser of a client device). Key-exchange protocols that provide PFS are ephemeral because they use a temporary public/private key pair to generate the shared secret].
Regarding claim 4, while Kancharla discloses, wherein the second block is configured to receive a key from the first block, the key purportedly sent from the second computer system to the first block for use in establishing the shared secret. [¶¶20-22, Once the ECDH session is established between the server 108 and client 110, the third party PFS traffic monitoring module 106 (e.g., Extrahop) is configured to capture, monitor, and analyze PFS network traffic data exchanged between the server 108 and client 110. Note that the PFS traffic monitoring module 106 has access to the ECDH public parameters of the server 108 and client 110].
Furthermore, Campagna discloses [ see FIGS 2-3, and corresponding text for more detail, ¶55, the second client 304 may have a second ECDH key pair 312 that includes a private key d.sub.B and public key Q.sub.B. The second client's public key Q.sub.B 320 may be provided to the first client 302 in a similar manner to the key exchange described in FIG. 2. A message 314 with the second client's identity information and public key Q.sub.B may be provided to the cryptography service 306 as part of an Authenticate request and a MAC tag 316 may be generated using a customer master key associated with the second client 304, provided to the second client 304, and forwarded to the first client 302].
Regarding claim 5, Kancharla discloses, wherein generating authentication data by performing a cryptographic authentication operation based on the data received from the first block comprises obtaining a digital signature based on the data and an authentication private key associated with an authentication certificate of the first computer system, wherein the digital signature is provided from the second block to the first block for transmittal to the second computer system, wherein the first block is unable to obtain a digital signature using the authentication private key by any other means [¶20, In some embodiments, the HSM 102 is configured to accept a plurality of parameters passed by the server 108 via the API calls for the ECDH key generation. Such input parameters passed by the server 104 include but are not limited to ECDH curve type, client 110 as identified by its network/IP address, the random number and the SSL session ID generated by the server 108, RSA and/or Elliptic Curve Digital Signature Algorithm (ECDSA) key handle for signature, and supporting access rights and/or authorization policy data as to which third parties can access the derived keying materials and the server's ECDH parameters/keys. Upon receiving the parameters, the HSM 102 is configured to select an ECDH private key/parameters for the server 108 suitable for the ECDH curve type, store the ECDH private key in its memory (e.g., RAM) in a HSM table along/in association with the access rights and/or authorization policy data with key_ID attribute set to the SSL_Session_ID provided as an index to the HSM table. Note that the HSM 102 is FIPS 140-2 compliant, which meets FIPS compliance requirements of the ECDH private keys of the server 108. The HSM 102 is then configured to compute ECDH public key/parameters and signature of the server 108 based on private parameters and the random number received. The HSM 102 is then configured to provide the calculated ECDH public parameters signed by the RSA/ECDSA signature or authentication key of the server 108 to the client device 110 in the form of a server hello message. Note that all of the public/private keys of the server 108 are ephemeral session keys that are only valid and used during the current ECDH session. The ephemeral keys will expire and be removed from the HSM table after the current ECDH session or timeout.
Regarding claim 8, Kancharla does not explicitly disclose, however, Campagna discloses, wherein the authentication private key is stored within the second block and not shared with the first block [ see FIGS. 2-3, and corresponding text for more details, [¶48, In some embodiments, an ECDH key pair 208 is generated by the client 202. The ECDH key pair may include a private key d.sub.A and a public key Q.sub.A. However, other types of asymmetric key pairs may be generated instead, and the private key kept secret from other parties].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of Kancharla by incorporating “implementing elliptic curve Diffie-Hellman key exchange to compute a shared secret for secure communication”, as taught by Campagna. One could have been motivated to do so in order to assure the clients that the cryptography service cannot compute the shared secret and eavesdrop or perform a “man-in-the-middle” attack for cryptographically protected communication sessions [ Campagna, ¶24].
Regarding claim 11, Kancharla does not explicitly disclose, however, Campagna, wherein the second block is relatively more trusted than the first block. [Abstract, A system may transmit, to a first entity, data to indicate an association between the first entity and a public key, wherein the public key is to be used to establish a cryptographically protected communications session between the first entity and a second entity, receive the data in response to a request to verify the association, and transmit, to the second entity, an indication that the data is valid. The system may be a cryptography service that is partially by the first and second entities. A partially trusted system can a computer system that is trusted in some respects but not trusted in other respects. A partially trusted cryptography service may be trusted to generate digital signatures and verify authenticity of digital signatures, but not trusted with access to a cryptographic key that can be used to access a cryptographically protected communications between a first entity and a second entity], and [¶41, [0041] FIG. 2 shows an illustrative environment 200 for exchanging an ECDH key pair using a partially trusted cryptography service 206…].
Regarding claim 12, Kancharla discloses, wherein the second block is implemented wholly in hardware and comprises a programmable logic device, PLD, a field programmable gate array, FPGA, and/or an application specific integrated circuit, ASIC, and/or the second block does not comprise a Turing machine. [¶14, In the example of FIG. 1, the system 100 includes at least a hardware security module (HSM) 102, a computing unit/appliance/host 104 having one or more web service providers/servers 108 running on it, and a third party PFS traffic monitoring module 106. In some embodiments, the HSM 102 is a multi-chip embedded hardware/firmware cryptographic module having software, firmware, hardware, or another component that is used to effectuate a purpose. The HSM 102 is certified under Federal Information Processing Standard (FIPS) for performing secured key management cryptographic operations. The computing unit/appliance/host 104 comprises one or more of a CPU or microprocessor, a memory (also referred to as primary memory) such as RAM, and a storage unit such as a non-volatile memory (also referred to as secondary memory) with software instructions stored in for practicing one or more processes… The processes may alternatively be at least partially embodied in a digital signal processor formed of application specific integrated circuits (ASIC) for performing the processes].
Regarding claim 13, Kancharla discloses, wherein the second block is implemented in a combination of hardware and formally verifiable software. [¶14, In the example of FIG. 1, the system 100 includes at least a hardware security module (HSM) 102, a computing unit/appliance/host 104 having one or more web service providers/servers 108 running on it, and a third party PFS traffic monitoring module 106. In some embodiments, the HSM 102 is a multi-chip embedded hardware/firmware cryptographic module having software, firmware, hardware, or another component that is used to effectuate a purpose. The HSM 102 is certified under Federal Information Processing Standard (FIPS) for performing secured key management cryptographic operations. The computing unit/appliance/host 104 comprises one or more of a CPU or microprocessor, a memory (also referred to as primary memory) such as RAM, and a storage unit such as a non-volatile memory (also referred to as secondary memory) with software instructions stored in for practicing one or more processes… The processes may alternatively be at least partially embodied in a digital signal processor formed of application specific integrated circuits (ASIC) for performing the processes], and [¶16].
Regarding claim 14, Kancharla disclose, however, wherein the handshaking messages exchanged between the first block and the second block are encrypted [¶17, In the example of FIG. 1, the HSM 102 implemented via the HSM appliance 202 described above is configured to provide a FIPS 140-2 overall Level 3 certified security solution to a plurality of users/web service providers by offloading key storage and cryptographic operations from the server 104 running on the host 102. For a non-limiting example, the ephemeral keys, parameters, and secret used by the server 104 for crypto (encryption/decryption) operations of secured PFS communication/traffic over the Internet can be offloaded to, stored, and maintained on the HSM 102.], and [¶26, In some embodiments, the HSM 102 is configured to accept and store various types of key-related objects, which include but are not limited to secured authentication credentials, client/server generated/imported keys, parameters, PMS, and certificates of the web service host/server 104. Here, all of the objects stored in the HSM 102 are maintained in an isolated and tamper-proof environment, e.g., FIPS 140-2 Level 3 certified hardware implementation of the HSM 102 (e.g., HSM adapter 200), with nothing being stored anywhere else in the system 100. In some embodiments, the objects are encoded and encrypted via an encryption key before being stored in the HSM 102, wherein the encryption key is unique for the HSM 102. Consequently, no entity except for owner/server 104 and those on the ACL list can have access the PMS and keys maintained by the HSM 102], and [¶29].
Regarding claim 15, Kancharla discloses, wherein the first block is configured to encrypt and decrypt handshaking messages exchanged between the first block and the second block using one or more keys provided from the second block to the first block, the one or more keys derived by the second block from the shared secret based on a cryptographic one-way function [¶17, In the example of FIG. 1, the HSM 102 implemented via the HSM appliance 202 described above is configured to provide a FIPS 140-2 overall Level 3 certified security solution to a plurality of users/web service providers by offloading key storage and cryptographic operations from the server 104 running on the host 102. For a non-limiting example, the ephemeral keys, parameters, and secret used by the server 104 for crypto (encryption/decryption) operations of secured PFS communication/traffic over the Internet can be offloaded to, stored, and maintained on the HSM 102.], and [¶26, In some embodiments, the HSM 102 is configured to accept and store various types of key-related objects, which include but are not limited to secured authentication credentials, client/server generated/imported keys, parameters, PMS, and certificates of the web service host/server 104. Here, all of the objects stored in the HSM 102 are maintained in an isolated and tamper-proof environment, e.g., FIPS 140-2 Level 3 certified hardware implementation of the HSM 102 (e.g., HSM adapter 200), with nothing being stored anywhere else in the system 100. In some embodiments, the objects are encoded and encrypted via an encryption key before being stored in the HSM 102, wherein the encryption key is unique for the HSM 102. Consequently, no entity except for owner/server 104 and those on the ACL list can have access the PMS and keys maintained by the HSM 102], and [¶29].
Regarding claim 16, Kancharla discloses, wherein the cryptographically secured connection complies with Transport Layer Security version 1.3.[¶12, Ephemeral keys are used by PFS in key agreement process instead of long-term keys to prevent information leakage from old sessions in case of long-term key compromise as discussed above. Under the proposed approach, third party applications and modules such as the traffic monitoring module are enabled to look into data exchanged during the secured communication session (e.g., SSL/TLS) using the ephemeral keys or secret maintained and shared by the HSM for traffic monitoring purposes. ].
Regarding claim 17, Kancharla discloses, wherein the cryptographically secured connection is initiated by the second computer system [¶¶17-21, 29, In some embodiments, the server 108 is configured to communicate securely with a client device 110 requesting connection and service by the server 108 via Elliptic curve Diffie-Hellman (ECDH) protocol.].
Regarding claim 18, Kancharla discloses wherein the cryptographically secured connection is initiated by the first computer system [¶¶17-21, 29, During the handshake to establish a secured ECDH communication session between the server 108 and the client 110, the client 110 may initiate a client hello message over a non-secured communication channel requesting connection to the server 108. After receiving the client hello message, the server 108 is configured to generate an unique random number and an ID for a SSL session with the client 110. Here, the session ID is an unique ID derived from the unique random number. ].
Regarding claim 19, Kancharla discloses, wherein the second block is not configured to perform the functionality of the first block. [¶14], and [¶17, see FIG. 1, the HSM 102 (equated to first block) is connected/coupled to the host 104 running the server 108 (equated to second block) via a PCIe bus in order to interact with and to offload the ephemeral keys from the VMs 108 in a secure manner].
Regarding claim 20, Kancharla discloses, wherein the second block is configured to perform only a limited set of predetermined operations that is not modifiable by data received from the first block. [¶14], and [¶17, see FIG. 1, the HSM 102 (equated to first block) is connected/coupled to the host 104 running the server 108 (equated to second block) via a PCIe bus in order to interact with and to offload the ephemeral keys from the VMs 108 in a secure manner].
Regarding claim 21, Kancharla discloses, further comprising an application block, wherein the further encrypted messages received from the second computer system are decrypted by the second block using the one or more session keys and sent as plaintext to the application block, and wherein plaintext messages received from the application block are encrypted by the second block using the one or more session keys and sent as further encrypted messages to the second computer system. [ ¶¶16, 20-21, In some embodiments, the HSM 102 is configured to accept a plurality of parameters passed by the server 108 via the API calls for the ECDH key generation. Such input parameters passed by the server 104 include but are not limited to ECDH curve type, client 110 as identified by its network/IP address, the random number and the SSL session ID generated by the server 108, RSA and/or Elliptic Curve Digital Signature Algorithm (ECDSA) key handle for signature, and supporting access rights and/or authorization policy data as to which third parties can access the derived keying materials and the server's ECDH parameters/keys. Upon receiving the parameters, the HSM 102 is configured to select an ECDH private key/parameters for the server 108 suitable for the ECDH curve type, store the ECDH private key in its memory (e.g., RAM) in a HSM table along/in association with the access rights and/or authorization policy data with key_ID attribute set to the SSL_Session_ID provided as an index to the HSM table. Note that the HSM 102 is FIPS 140-2 compliant, which meets FIPS compliance requirements of the ECDH private keys of the server 108. The HSM 102 is then configured to compute ECDH public key/parameters and signature of the server 108 based on private parameters and the random number received. The HSM 102 is then configured to provide the calculated ECDH public parameters signed by the RSA/ECDSA signature or authentication key of the server 108 to the client device 110 in the form of a server hello message. Note that all of the public/private keys of the server 108 are ephemeral session keys that are only valid and used during the current ECDH session. The ephemeral keys will expire and be removed from the HSM table after the current ECDH session or timeout…].
Regarding claim 22, Kancharla discloses, wherein the second block is configured to perform only a limited set of predetermined operations that is not modifiable by data received from the application block. [ ¶¶16, 20-21, In some embodiments, the HSM 102 is configured to accept a plurality of parameters passed by the server 108 via the API calls for the ECDH key generation. Such input parameters passed by the server 104 include but are not limited to ECDH curve type, client 110 as identified by its network/IP address, the random number and the SSL session ID generated by the server 108, RSA and/or Elliptic Curve Digital Signature Algorithm (ECDSA) key handle for signature, and supporting access rights and/or authorization policy data as to which third parties can access the derived keying materials and the server's ECDH parameters/keys. Upon receiving the parameters, the HSM 102 is configured to select an ECDH private key/parameters for the server 108 suitable for the ECDH curve type, store the ECDH private key in its memory (e.g., RAM) in a HSM table along/in association with the access rights and/or authorization policy data with key_ID attribute set to the SSL_Session_ID provided as an index to the HSM table. Note that the HSM 102 is FIPS 140-2 compliant, which meets FIPS compliance requirements of the ECDH private keys of the server 108. The HSM 102 is then configured to compute ECDH public key/parameters and signature of the server 108 based on private parameters and the random number received. The HSM 102 is then configured to provide the calculated ECDH public parameters signed by the RSA/ECDSA signature or authentication key of the server 108 to the client device 110 in the form of a server hello message. Note that all of the public/private keys of the server 108 are ephemeral session keys that are only valid and used during the current ECDH session. The ephemeral keys will expire and be removed from the HSM table after the current ECDH session or timeout…].
Regarding claim 23, Kancharla discloses, wherein the predetermined set of operations is modifiable only via instructions received via one or more interfaces that are separate from the first block and the application block. [¶16, FIG. 2 depicts an example of hardware implementation 200 of the HSM 102 depicted in FIG. 1. As shown in the example of FIG. 2, the FIPS 140-2 Level 2 and 3 certified computing unit HSM appliance 200 includes one or more CPUs, RAM, and storage unit. The HSM appliance 200 further includes a FIPS-certified SR-IOV-capable HSM adapter 202, which further includes an SR-IOV PCIe bridge 206 connecting the HSM adapter 202 to the CPUs via a first PCIe connection (e.g., PCIe Gen2 x8), wherein PCIe is a high-speed serial computer expansion bus standard designed to support hardware I/O virtualization to enable maximum system bus throughput, low I/O pin count and a small physical footprint for bus devices. The bridge 206 is further configured to connect to a multi-core processor 208 (e.g., a multi-core MIPS64 processor such as OCTEON CN6130) of the HSM adapter 202 across a high speed communication interface (e.g., 10G XAUI Interface). The HSM adapter 202 further includes a security processor 210 (e.g., NITROX CNN3560) via a second PCIe connection (e.g., PCIe Gen 2 x4), wherein the security processor 210 is configured to enable cryptographic acceleration by performing crypto operations with hardware accelerators and embedded software implementing security algorithms. In some embodiments, the HSM appliance 200 is supplied and preconfigured with default network and authentication credentials so that the HSM appliance 200 can be FIPS/Common Criteria/PCI compliant for PFS traffic monitoring].
Regarding claim 24, Kancharla discloses, wherein the second block is configured to perform only a limited set of predetermined operations that is modifiable by data received from the application block. [¶16, FIG. 2 depicts an example of hardware implementation 200 of the HSM 102 depicted in FIG. 1. As shown in the example of FIG. 2, the FIPS 140-2 Level 2 and 3 certified computing unit HSM appliance 200 includes one or more CPUs, RAM, and storage unit. The HSM appliance 200 further includes a FIPS-certified SR-IOV-capable HSM adapter 202, which further includes an SR-IOV PCIe bridge 206 connecting the HSM adapter 202 to the CPUs via a first PCIe connection (e.g., PCIe Gen2 x8), wherein PCIe is a high-speed serial computer expansion bus standard designed to support hardware I/O virtualization to enable maximum system bus throughput, low I/O pin count and a small physical footprint for bus devices. The bridge 206 is further configured to connect to a multi-core processor 208 (e.g., a multi-core MIPS64 processor such as OCTEON CN6130) of the HSM adapter 202 across a high speed communication interface (e.g., 10G XAUI Interface). The HSM adapter 202 further includes a security processor 210 (e.g., NITROX CNN3560) via a second PCIe connection (e.g., PCIe Gen 2 x4), wherein the security processor 210 is configured to enable cryptographic acceleration by performing crypto operations with hardware accelerators and embedded software implementing security algorithms. In some embodiments, the HSM appliance 200 is supplied and preconfigured with default network and authentication credentials so that the HSM appliance 200 can be FIPS/Common Criteria/PCI compliant for PFS traffic monitoring].
Regarding claim 25, Kancharla discloses, wherein the second block is separated from the first block by a communications interface over which data is exchanged between the first block and the second block, wherein the first computer system is configured to check data sent over the communications interface against one or more interface rules and prevent data sent from the first block to the second block over the communications interface from being acted upon by the second block in case of non-compliance of the data with the one or more interface rules. [Abstract, A new approach is proposed to support monitoring Perfect Forward Secrecy (PFS) network traffic by utilizing a hardware security module (HSM) appliance. Here, the HSM appliance is a high-performance, Federal Information Processing Standards (FIPS) 140-compliant security hardware with embedded firmware, which can be used for management and sharing of ephemeral keys used in a secured PFS communication session between two parties. Specifically, the HSM allows a server to share one or more of its ephemeral keys and/or parameters used in PFS traffic during the session with a third party under specified access rights and/or authorization, wherein the third party can be but is not limited to a traffic monitoring module. The HSM allows the third party to access the ephemeral keys stored on the HSM under the specified access rights and/or authorization so that the third party may decrypt and run analytics on the PFS traffic captured during the session], and [¶¶12, 16, 20].
Regarding claim 26, Kancharla discloses, wherein the second block is configured to perform a compliance check on data received from the first block over the communications interface prior to acting on the data and the second block is configured not to act on the data in case of non-compliance of the data with the one or more interface rules[Abstract, A new approach is proposed to support monitoring Perfect Forward Secrecy (PFS) network traffic by utilizing a hardware security module (HSM) appliance. Here, the HSM appliance is a high-performance, Federal Information Processing Standards (FIPS) 140-compliant security hardware with embedded firmware, which can be used for management and sharing of ephemeral keys used in a secured PFS communication session between two parties. Specifically, the HSM allows a server to share one or more of its ephemeral keys and/or parameters used in PFS traffic during the session with a third party under specified access rights and/or authorization, wherein the third party can be but is not limited to a traffic monitoring module. The HSM allows the third party to access the ephemeral keys stored on the HSM under the specified access rights and/or authorization so that the third party may decrypt and run analytics on the PFS traffic captured during the session], and [¶¶12, 16, 20].
Regarding claim 27, Kancharla discloses, wherein the communications interface between the first block and the second block includes an interface manager configured to a perform a compliance check on data sent from the first block over the communications interface and prevent the data sent from the first block from being received by the second block in case of non-compliance with the one or more interface rules [Abstract, A new approach is proposed to support monitoring Perfect Forward Secrecy (PFS) network traffic by utilizing a hardware security module (HSM) appliance. Here, the HSM appliance is a high-performance, Federal Information Processing Standards (FIPS) 140-compliant security hardware with embedded firmware, which can be used for management and sharing of ephemeral keys used in a secured PFS communication session between two parties. Specifically, the HSM allows a server to share one or more of its ephemeral keys and/or parameters used in PFS traffic during the session with a third party under specified access rights and/or authorization, wherein the third party can be but is not limited to a traffic monitoring module. The HSM allows the third party to access the ephemeral keys stored on the HSM under the specified access rights and/or authorization so that the third party may decrypt and run analytics on the PFS traffic captured during the session], and [¶¶12, 16, 20].
Regarding claim 28, while Kancharla discloses a system comprising the first computer system according to claim 1 in combination with the second computer system[ [¶15, In the example of FIG. 1, the HSM 102, the server 104, the third party PFS traffic monitoring module 106, and a client device 110 requesting service from the server 104 each has a communication interface].
Furthermore, Campagna discloses [¶29, FIG. 1 shows a diagram 100 illustrating a context in which various techniques of the present disclosure may be utilized. In this particular example, the diagram 100 shows a first client “Client A” 102 and a second client “Client B” 104 communicating via a cryptographically protected communication session 114. A cryptography service 106 may be utilized by the clients 104 and 106 to perform various cryptographic operations and to store and access cryptographic key].
Regarding claims 29-30, these claims are interpreted and rejected for the same rational set forth in claim 1.
Claims 6, and 9-10 are rejected under 35 U.S.C. 103 as being unpatentable over US Patent No. (US2018/0062854) issued to Kancharla (filed in IDS 09/06/2023),and in view of US Patent No. (US2017/0310652) issued to Campagna, and further in view of Gero (WO2016073552 A1) (filed in IDS 09/06/2023).
Regarding claim 6, Kancharla, and Campagna do not explicitly disclose, however, Gero discloses wherein the second block is configured to obtain a digital signature based on the received data by obtaining a hash of a transcript of handshaking messages exchanged between the first block and the second computer system and by obtaining a digital signature of the hash [ Pages 15-16, At step 8, the client sends a Finished message with a hash of all prior messages to ensure that no modifications occurred during the handshake. At step 9, the server (which can now generate the pre- master secret based on its own secret parameter and the dh_Yc parameter of the client) sends a ChangeCipherSpec message to the client indicating that it, too, is now changing to use the agreed-upon symmetric cipher (from step 2). At step 10, the server sends a Finished message, once again with a hash of all prior messages to ensure that no modifications occurred during the handshake].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of Kancharla, and Campagna by incorporating “hashing all prior messages”, as taught by Gero. One could have been motivated to do so in order for ensuring that no modification occurred during the handshake [ Gero, Pages 15-16, At step 8, and 10].
Regarding claim 9, Kancharla, and Campagna do not explicitly disclose, however, Gero discloses, wherein the first computer system includes a digital signing block that is separate from the second block and the digital signing block stores the authentication private key, wherein the second block is configured to obtain the digital signature of the hash by instructing the digital signing block to digitally sign the hash using the authentication private key[ Page 15, At step 4.2, and in contrast to the protocol in FIG. 5, the server 602 then sends (to the EDH Proxy 604) the given dh_p, dh_g, and dh_Ys parameters, along with the server and client nonces. At step 4.3, the EDH (Ephemeral Diffie- Hellman) proxy 604, having the RSA private key, signs the parameters and nonces and returns the signature to the server. The communications between the server and the EDH proxy are preferably over a mutually authenticated transport].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of Kancharla, and Campagna by incorporating “EDH (Ephemeral Diffie- Hellman) proxy server”, as taught by Gero. One could have been motivated to do so in order for implementing an infrastructure delivery platform provides a proxy service as an enhancement to the TLS/SSL protocol to off-load to an external server the generation of a digital signature, the digital signature being generated using a private key that would otherwise have to be maintained on a terminating server. Using this service, instead of digitally signing (using the private key) "locally," the terminating server proxies given public portions of ephemeral key exchange material to the external server and receives, in response, a signature validating the terminating server is authorized to continue with the key exchange. [ Gero, Abstract].
Regarding claim 10, Kancharla, and Campagna do not explicitly disclose, however, Gero discloses, wherein the digital signing block comprises one or more of: a hardware security module, HSM, and a trusted platform module, TPM [ Pages 15-16, At step 4.2, and in contrast to the protocol in FIG. 5, the server 602 then sends (to the EDH Proxy 604) the given dh_p, dh_g, and dh_Ys parameters, along with the server and client nonces. At step 4.3, the EDH (Ephemeral Diffie- Hellman) proxy 604, having the RSA private key, signs the parameters and nonces and returns the signature to the server. The communications between the server and the EDH proxy are preferably over a mutually authenticated transport…The EDH proxy may be located in a secure physical environment].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of Kancharla, and Campagna by incorporating “by storing EDH (Ephemeral Diffie- Hellman) proxy server in a secure environment”, as taught by Gero. One could have been motivated to do so in order for implementing an infrastructure delivery platform provides a proxy service as an enhancement to the TLS/SSL protocol to off-load to an external server the generation of a digital signature, the digital signature being generated using a private key that would otherwise have to be maintained on a terminating server. Using this service, instead of digitally signing (using the private key) "locally," the terminating server proxies given public portions of ephemeral key exchange material to the external server and receives, in response, a signature validating the terminating server is authorized to continue with the key exchange. [ Gero, Abstract, Pages 15-16].
Claim 7 is rejected under 35 U.S.C. 103 as being unpatentable over US Patent No. (US2018/0062854) issued to Kancharla, (filed in IDS 09/06/2023), and in view of US Patent No. (US2017/0310652) issued to Campagna, and in view of Gero (WO2016073552 A1) (filed in IDS 09/06/2023), and further in view of Le Saint (US2015/0372811) (filed in IDS 09/06/2023).
Regarding claim 7, Kancharla, Campagna , and Gero do not explicitly disclose, however, Le Saint discloses The first computer system of claim 6, wherein the second block is configured to determine whether to obtain the digital signature by determining, based on header information in the handshaking messages included in the transcript, an expected location of the key in the transcript and performing a data comparison between data at the expected location and the key provided by the second block to the first block [¶224, At step F12, the first session key is used to generate encrypted request data (EncData.sub.F) using an authenticated encryption (AE) algorithm. The request data includes a pre-defined header (“KC.sub.—0_V”), a first device identifier, a first device control byte, a cipher suite specification, identification data, and a first device certificate], and [¶¶241-242, At step F32, the second session key is used to decrypt (AE.sup. −1) the encrypted response data. The resulting response data includes a pre-defined header (Header), a second device certificate, a cryptographic nonce (N.sub.S), a second device control byte (CB.sub.S), a new second device certificate (NewC.sub.S) to be used in future communication, a new cipher suite specification (NewCipherSpec) to be used in future communication, and a payload (Payload). At step F33, the pre-defined header is verified by checking that it matches an expected value. The second device control byte is also verified].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of Kancharla, Campagna, and Gero by incorporating “a request data which includes pre-defined header, a first device identifier, a first device control byte, a cipher suite specification, identification data, and a first device certificate”, as taught by Le Saint. One could have been motivated to do so in order for verify a digital signature which supposedly made by an entity by an elliptic curve digital signature algorithm (ECDSA) and a public key of a trusted certificate authority (PubCA) [ Le Saint, ¶¶28, 128].
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
See 892 submitted with this application for more relevant references.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SHAHRIAR ZARRINEH whose telephone number is (571)272-1207. The examiner can normally be reached Monday-Friday, 8:30am-5:30pm.
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) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Jorge Ortiz-Criado can be reached at 571-272-7624. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/SHAHRIAR ZARRINEH/Primary Examiner, Art Unit 2496