Office Action 3: Notice of Allowance (2024-07-31)

CLAIMS:
IN THE CLAIMS:

1\. (Currently amended) An authentication method of a prover device to a verifier device,
the method comprising:at least two successive verification operations, each operation comprising, successively:
generating, by the verifier device, first data from second data generated by the verifier device in a preceding verification operation;
sending, by the verifier device, the first data to the prover device;
generating, by the prover device, third data and fourth data used by a following verification operation, by applying a first function taking as input at least the first data and the fourth data generated in the preceding verification operation;
sending, by the prover device, the third data to the verifier device;
verifying, by the verifier device, the third data using a second function taking as input the first data and the third data; and
outputting, by the verifier device, information indicating whether the verification was successful, and the second data used by the following verification operation; and
authenticating the prover device to the verifier device in response to:
for each verification operation, the information indicating that the verification was successful; and
the fourth data of the prover device and the second data of the verifier device of a last verification operation being correct.
2\. (Previously presented) The method according to claim 1, wherein, during implementation of a first verification operation, the verifier device uses fifth data to generate the first data, and the prover device uses sixth data to generate the third data and the fourth data.
3\. (Original) The method according to claim 2, wherein the fifth data is different for each verification operation, and the sixth data is different for each verification operation.

4\. (Previously presented) The method according to claim 2, wherein, during implementation of each verification operation, the verifier device uses the fifth data to generate the first data, and the prover device uses the sixth data to generate the third data and the fourth data.
5\. (Previously presented) The method according to claim 2, wherein the verifier device generates the first data from the second data generated in the preceding verification operation and the fifth data, and the first function takes as input the first data, the fourth data generated in the preceding verification operation, and the sixth data.
6\. (Previously presented) The method according to claim 1, further comprising an identification operation preceding the at least two successive verification operations, the identification operation comprising:
the prover and verifier devices exchanging identification numbers; and
in response to at least one of the devices not recognizing the identification number of the other device, implementing the at least two successive verification operations.
7\. (Original) The method according to claim 1, wherein the first function of one of the at least two successive verification operations is different from the first function of another one of the at least two successive verification operations.
8\. (Original) The method according to claim 1, wherein the second function of the at least two successive verification operations is different from the second function of another of the at least two successive verification operations.
9\. (Previously presented) The method according to claim 1, wherein the prover and verifier devices send data to each other in an encrypted manner.

10\. (Previously presented) The method according to claim 9, wherein, during implementation of each of the at least two successive verification operations, the prover and verifier devices send the data to each other in the encrypted manner using a first encryption key.

11\. (Original) The method according to claim 10, wherein the first encryption key is different for each implementation of each of the at least two successive verification operations.

12\. (Original) The method according to claim 11, wherein the first encryption key depends on the first encryption key of the preceding verification operation.

13\. (Previously presented) The method according to claim 1, wherein, of the at least two successive verification operations, there is at least a first verification operation in which the second function generates seventh data, in addition, which is sent to the verifier device, andof the at least two successive verification operations there is at least one second verification operation, successive to the first verification operation, wherein:
the verifier device further generates eighth data by applying the first function to the seventh data and sends the eighth data to the prover device; and
the prover device decrypts ninth data using the eighth data to generate the third data.

14\. (Previously presented) The method according to claim 13, wherein the prover device uses the eighth data to decrypt ninth data, and the first function further takes the ninth data as input to generate the third data.

15\. (Currently amended) A prover device comprising:a non-transitory memory comprising instructions; and
a processor in communication with the non-transitory memory, wherein the processor executes the instructions to authenticate the prover device to a verifier device, the

authentication comprising:at least two successive verification operations, each operation comprising, successively:
receiving first data from the verifier device, the first data generated by the verifier device from second data generated by the verifier device in a preceding verification operation;
generating third data and fourth data used by a following verification operation, by applying a first function taking as input at least the first data and the fourth data generated in the preceding verification operation; and sending the third data to the verifier device for verification using a second function taking as input the first data and the third data; and verifying the prover device to authorized to communicate with the verifier device in response \[\[to:\]\] to the fourth data of the prover device of a last verification operation being correct.

16\. (Previously presented) The prover device according to claim 15, wherein the non- transitory memory is configured to store the first, third, and fourth data.

17\. (Previously presented) The prover device according to claim 15, wherein the authentication further comprises an identification operation preceding the at least two successive verification operations, the identification operation comprising:exchanging identification numbers with the verifier device; and
in response to at least one of the devices not recognizing the identification number of the other device, implementing the at least two successive verification operations.

18\. (Currently amended) A verifier device comprising:a non-transitory memory comprising instructions; and

a processor in communication with the non-transitory memory, wherein the processor executes the instructions to authenticate a prover device to the verifier device, the authentication comprising:at least two successive verification operations, each operation comprising, successively:
generating first data from second data generated by the verifier device in a preceding verification operation;
sending the first data to the prover device;
receiving third data from the prover device, the third data and fourth data used by a following verification operation generated by the prover device by applying a first function taking as input at least the first data and the fourth data generated in the preceding verification operation;
verifying the third data using a second function taking as input the first data and the third data; and
outputting information indicating whether the verification was successful, and the second data used by the following verification operation; and
verifying the prover device to authorized to communicate with the verifier device in response to:
for each verification operation, the information indicating that the verification was successful; and
the second data of the verifier device of a last verification operation being correct.

19\. (Previously presented) The verifier device according to claim i8, wherein the non- transitory memory is configured to store the first, second, and fourth data and the information.

20\. (Previously presented) The verifier device according to claim 18, wherein the authentication further comprises an identification operation preceding the at least two successive verification operations, the identification operation comprising:exchanging identification numbers with the prover device; and
in response to at least one of the devices not recognizing the identification number of the other device, implementing the at least two successive verification operations.

OFFICE 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 .
Allowable Subject Matter
The following is an examiner’s statement of reasons for allowance:
The prior art of record fails to teach or fairly suggest indicating successful verification of a first device transmitting an authentication request to a verification device, upon at least two consecutive verification operations being performed, upon authentication data being transmitted between the first device and the verification device, using data generated by the verification device in a previous verification operation and additional data generated by the first device for a subsequent verification operation, via applying a function using data generated in a previous verification operation, using a second function using previous data as an input for verifying the first device and outputting confirmation of successful verification of the first device, along with data to be used by the subsequent verification operation, in the specific manner and combinations recited in claims 1-20.
The closest related prior art are cited to state the general state of the art and are not considered to teach the distinguishing features noted above. The prior art includes:
(i) 	US PG Pub Kuhlman et al (US 7,363,492), which teaches a verifier device authenticating a requesting prover device using data retrieved from previous authentication results;
(ii) 	US PG Pub Cormode et al (US 2012/0143830), which discloses using preceding hash values from previous secure sessions to authenticate a prover device using a verifier device;
(iii) 	NPL document “Zero Knowledge Authentication” – Rob Leslie, Sedicii, 07/30/2015; and
(iv) 	NPL document “Secure Comparator: a ZKP-Based Authentication System” – Korchagin et al, Cossacklabs, 03/2015.
After thorough review of related prior art, the application has been deemed allowable because of the limitations of indicating successful verification of a first device transmitting an authentication request to a verification device, upon at least two consecutive verification operations being performed, upon authentication data being transmitted between the first device and the verification device, using data generated by the verification device in a previous verification operation and additional data generated by the first device for a subsequent verification operation, via applying a function using data generated in a previous verification operation, using a second function using previous data as an input for verifying the first device and outputting confirmation of successful verification of the first device, along with data to be used by the subsequent verification operation, recited in the specific manner and combinations recited within the claims. Upon an extensive search and review, none of the cited prior art taught the specified limitation or provided language for the specified limitations.
Any comments considered necessary by applicant must be submitted no later than the payment of the issue fee and, to avoid processing delays, should preferably accompany the issue fee. Such submissions should be clearly labeled “Comments on Statement of Reasons for Allowance.”
Conclusion

APPLICANT REBUTTAL: REMARKS
Claims 1-20 are pending, with claims 1, 15, and 18 being independent. Claims 1, 15, and 18 have been amended. No new subject matter has been added. Specification Amendment
Basis for the amendment to the Specification may be found, for example, in Figures 3-7. Allowable Subject Matter
Applicant acknowledges with appreciation the indication of allowable subject matter regarding claims 6, 13, 14, 17, and 20, which stand objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims. Section 103 Rejections
Claims 1-5, 7-12, 15-16, and 18-19 are rejected under 35 U.S.C. @ 103 as being
unpatentable over Vendelbo (US Pat. Appl. Publ. 2018/0352433) in view of Jun (US Pat. Appl. Publ. 2015/0278506) and Peeters (US Pat. Appl. Publ. 2020/0272724). Applicant respectfully traverses these rejections.
Independent claim i recites an authentication method of a prover device to a verifier device, the method comprising:
at least two successive verification operations, each operation comprising,
successively:
generating, by the verifier device, first data from second data generated by the verifier device in a preceding verification operation;
sending, by the verifier device, the first data to the prover device; generating, by the prover device, third data and fourth data used by a following verification operation, by applying a first function taking as input at least the first data and the fourth data generated in the preceding verification
operation;
sending, by the prover device, the third data to the verifier device; verifying, by the verifier device, the third data using a second function taking as input the first data and the third data; and
outputting, by the verifier device, information indicating whether the verification was successful, and the second data used by the following
verification operation; and
authenticating the prover device to the verifier device in response to:
for each verification operation, the information indicating that the verification was successful; and
the fourth data of the prover device and the second data of the verifier device of a last verification operation being correct.
Vendelbo, Jun, and Peeters, even if possible to combine, do not teach or suggest these all
of these claim elements, nor do they remedy the below-described deficiencies of each other. In
particular, it is not possible to map the references onto the recited claim elements as asserted in
the Office Action.
Regarding claim 1, the Office Action states that Vendelbo teaches:
an authentication method of a prover device to a verifier device (fig. 1,
'8/'io), the method comprising at least two successive verification operations
(par [0014], "second authentication request"), each operation comprising,
successively:
sending, by the verifier device, the first data to the prover device (fig. 2,
'108 &par [0135], which discloses transmitting the information to the user
application of the prover device);
authenticating the prover device to the verifier device in response to:
for each verification operation, the information indicating that the
verification was successful (par [0006], lines 10-16, "second authentication data
is successful").
E.g., Office Action, p. 4 (May 22, 2024). The Office Action also states that Jun teaches:
generating, by the prover device, third data used by a following
verification operation (fig. 4,fig 6, par [0009] &par [0050], lines 10-20, which
disclose first user device creating pairing data associated with proof and the
first challenge information), by applying a first function taking as input at least
the first data generated in the preceding verification operation (fig. 4 &par
[0050], lines 12-16, "first function");
sending, by the prover device, the third data to the verifier device (par
[0022], lines 6-8, "transmitted from the primary device to the secondary
device"); and
verifying, by the verifier device, the third data using a second function
taking as input the first data and the third data (par [0021], lines 1-10 par
[0031], lines 1-10, which disclose performing secondary functions for
authentication using the pairing data).
E.g., id. at 5. The Office Action further states that Peeters teaches:
generating, by the verifier device, a first data from a second data (fig.1 &
par [0033], which disclose using a verifier to generate first data and receiving a
datum from a second circuit storing at least one first datum) generated in a
preceding verification operation (par [0035], lines 1-6, which discloses the
second data corresponding to a result of a first function);
outputting, by the verifier device, information indicating whether the
verification was successful (par [0059], lines 8-12, which discloses outputting an
indication of successful authentication), and the second data used by the
following verification operation (par [0059], lines 1-6, which discloses using
verification function verify to output authentication responses using secondary
datum);
generating, by the prover device, fourth data used by a following
verification operation (par [0029], which discloses fourth datum created representative of the first datum for authentication), by applying a first
function taking as input at least the fourth data generated in the preceding
verification operation (par [0030], which discloses implementing a first
function utilized to retrieve the fourth datum representative of the first datum
for authentication); and
verifying the fourth data of the prover device and the second data of the
verifier device of a last verification operation being correct (par [0040], lines 1- 15, which discloses verifying fourth data transmitted from the second device
and the fourth data corresponding to decrypted second data).
E.g., id. at 6-7. These interpretations do not align with Applicant's claims, as illustrated by the examples provided below. That is, several specific claim elements and relationships are not taught or suggested by any potential combination of Vendelbo, Jun, and Peeters.
As one example, claim 1 recites "at least two successive verification operations," which requires, in short, generating and sending by the verifier device, generating and sending by the prover device, verifying and outputting by the verifier device, another generating and sending by the verifier device, another generating and sending by the prover device, another verifying and outputting by the verifier device, and finally authenticating the prover device to the verifier device after the at least two successive verification operations. In contrast, Vendelbo discloses first and second authentication requests 108, 112, and responses, 110, 114, see, e.g., Vendelbo, Fig. 2,    [o137]-[0160], but these only can be considered as part of one verification operation of hearing aid 8 by user application 12, not at least two successive verification operations. Jun discloses one device generating a first authentication proof, receiving a second authentication proof from another device, and indicating a successful authentication if the two authentication proofs match. See, e.g., Jun, Figs. 5A-7, Abstract,    [0015], [oo21]-[oo22]. Peeters discloses verifier 100 generating datum C, prover 200 generating encoded datum R based on datum C, and verifier 100 verifying datum C and encoded datum R to providing output VF indicating a
result of the verification. See, e.g., Peeters, Fig. 1,    [0o53]-[oo59]. Thus, even assuming, solely for the purpose of this argument, that the references disclose one complete verification operation as recited by claim 1, the references do not teach or suggest at least two such verification operations in succession.
As another example, claim i recites that the second data used by the verifier device is generated by the verifier device in a preceding verification operation, and that the fourth data used by the prover device is generated by the prover device in a preceding verification operation. Taken from a different perspective, the second data generated by the verifier device is used by the verifier device in afollowing verification operation, and the fourth data generated by the prover device is used by the prover device in afollowing verification operation. Because the references disclose at most one verification operation as discussed above, the references do not teach or suggest second or fourth data used by one verification operation being generated in the preceding verification operation, or, similarly, second or fourth data that is generated by one verification operation being used by the following verification operation. That is, the references only disclose at most one verification operation, and therefore they do not teach or suggest second or fourth data being generated/used by two successive verification operations in authenticating a prover device to a verifier device.
As yet another example, claim i recites first and second data being generated by the verifier device, and third and fourth data being generated by the prover device.
[0063]. Peeters further discloses that
during a phase of personalizing the circuit 300, a circuit external to the circuit
300 retrieves the data A from the correspondence table 301 in order to calculate
the corresponding data A'. The data pairs (A, A') are then stored in the
correspondence table 301. Thus, during the active phase of the circuit 300, the
circuit 300 only stores the data A and A'. An advantage of this feature is that
neither the secret function f nor its inverse function flis known by the verifier
circuit 300.
E.g., id. at   [0071]. Not only does verifier circuit 300 not generate datum A', as it is generated by an external circuit during manufacture, verifier circuit 300 cannot generate datum A', because verifier circuit 300 does not know the secret function needed to generate datum A'.
Secondly, as acknowledged in the Office Action, Vendelbo and Jun do not explicitly teach generating, by the prover device, fourth data used by a following verification operation, by applying a first function taking as input at least the fourth data generated in the preceding verification operation. See Office Action at 6. Peeters does not remedy this deficiency of Vendelbo and Jun. Rather, Peeters discloses prover circuit 400 generating datum R based on datum A encoded with secret datum S possessed by prover circuit 400. See, e.g., Peeters at Fig. 2,    [oo77]-[0078]. Therefore, Peeters does not teach or suggest prover the device generating fourth data using first data and fourth data generated in the preceding verification operation, as required by claim 1.
Thus, the references, even if possible to combine, do not teach or suggest all of the first, second, third, and fourth data being generated by the proper devices according to claim 1.
For at least the above reasons, independent claim 1 is patentable over the prior art. Independent claims 15 and 18 each includes at least some similar relevant elements, and therefore these claims also are patentable over the prior art for associated reasons similar to those discussed above.
The remaining claims depend from and add further features to one of the independent claims. It is respectfully submitted that these dependent claims are allowable by reason of depending from an allowable claim, as well as for adding new features, and that it is not necessary to separately address these dependent claims. This should not be construed as an
acquiescence to Examiner's interpretation of those claims, or reading of those claim elements on the prior art, and Applicant expressly reserves the right to establish the patentability of those additional claim limitations, should the need arise. Conclusion


CITED REFERENCE SUMMARIES: Ref US7363492B2: Claims:
An authentication method having a selectable confidence level, comprising the steps of: (a) iteratively interacting between a prover and a verifier, wherein the prover and verifier are electronic devices that perform calculations and pass values between themselves that result from the calculations; (b) determining from at least one of the values whether each iteration yields one of a pass and fail result, wherein each iteration that yields a pass result establishes an authentication confidence level that is greater than an authentication level from a previous iteration, and wherein a fail result stops the iterations; (c) continuing to perform iterations, so long as each iteration achieves a pass result, until a count of iterations reaches a number sufficient to achieve a first authentication confidence level desired by the verifier; (d) allowing performance of a first task by the verifier in reliance on the first authentication confidence level; (e) continuing to perform iterations, so long as each iteration achieves a pass result, until a count of iterations reaches a number sufficient to achieve a second authentication confidence level desired by the verifier; (f) allowing performance of a second task by the verifier in reliance on the second authentication confidence level desired by the verifier; and (g) disallowing performance of the at least one task by the verifier when an iteration achieves a fail result before the second authentication confidence level is met.
(a) iteratively interacting between a prover and a verifier, wherein the prover and verifier are electronic devices that perform calculations and pass values between themselves that result from the calculations;
(b) determining from at least one of the values whether each iteration yields one of a pass and fail result, wherein each iteration that yields a pass result establishes an authentication confidence level that is greater than an authentication level from a previous iteration, and wherein a fail result stops the iterations;
(c) continuing to perform iterations, so long as each iteration achieves a pass result, until a count of iterations reaches a number sufficient to achieve a first authentication confidence level desired by the verifier;
(d) allowing performance of a first task by the verifier in reliance on the first authentication confidence level;
(e) continuing to perform iterations, so long as each iteration achieves a pass result, until a count of iterations reaches a number sufficient to achieve a second authentication confidence level desired by the verifier;
(f) allowing performance of a second task by the verifier in reliance on the second authentication confidence level desired by the verifier; and
(g) disallowing performance of the at least one task by the verifier when an iteration achieves a fail result before the second authentication confidence level is met.
An authentication method having a selectable confidence level according to claim 1 , wherein each iteration reduces doubt in the result by essentially half.
An authentication method having a selectable confidence level according to claim 1 , wherein the number sufficient to achieve the first authentication confidence level desired by the verifier in said step (c) is a number chosen by the verifier sufficient to satisfy the security requirements of an environment of at least the verifier.
An authentication method having a selectable confidence level according to claim 1 , wherein the method is performed among an ad-hoc network of the prover and at least one verifier.
An authentication method having a selectable confidence level according to claim 1 , wherein the prover is an automobile component and the verifier is an automobile system controller.
A verifier device comprising digital logic for performing the steps of claim 1 .
An authentication method having a selectable confidence level according to claim 1 , wherein said step (a) of iteratively interacting between a prover and a verifier uses same size, square matrices.
An authentication method having a selectable confidence level according to claim 7 , wherein entries of binary digits fill the same size, square matrices used in said step (a) of iteratively authenticating a prover by a verifier.
An authentication method having a selectable confidence level according to claim 7 , wherein said step (a) comprises the substeps of: (a)(a) establishing a private key matrix K, wherein the private key matrix K is a square matrix of a predetermined size; (a)(b) choosing a base matrix N of the same size as the private key matrix K; (a)(c) calculating a same-size, masked matrix M; (a)(d) picking by the prover a same-size, square matrix S for this iteration; (a)(e) calculating by the prover a same-size, commitment matrix C after the picking of the square matrix S in said step (a)(d) and sending the commitment matrix C from the prover to the verifier; and (a)(f) sending a request from the verifier to the prover after the receipt of the commitment matrix C in said step (a)(e), wherein the request comprises at least first and second request states; wherein said step (b) comprises the substeps of: (b)(g) on a first request state of the request, (b)(g)(1) the prover sending the square matrix S to the verifier, and (b)(g)(2) the verifier using received matrix S and the masked matrix M to verify the commitment matrix C, if not verifiable, then authentication fails, otherwise go to step (c)(i); and (b)(h) on a second request state of the request, (b)(h)(1) the prover calculating a same-size, masked key matrix V from the square matrix S and the private key matrix K and sending the masked key matrix V to the verifier, and (b)(h)(2) the verifier using received masked key matrix V and the base matrix N to verify the commitment matrix C, if not verifiable, then authentication fails, otherwise go to step (c)(i); and wherein said step (c) comprises the substeps of: (c)(i) determining whether to make another iteration to improve confidence and, if so, returning to step (a)(d) to make an additional iteration, otherwise issuing a pass decision.
wherein said step (a) comprises the substeps of:
(a)(a) establishing a private key matrix K, wherein the private key matrix K is a square matrix of a predetermined size;
(a)(b) choosing a base matrix N of the same size as the private key matrix K;
(a)(c) calculating a same-size, masked matrix M;
(a)(d) picking by the prover a same-size, square matrix S for this iteration;
(a)(e) calculating by the prover a same-size, commitment matrix C after the picking of the square matrix S in said step (a)(d) and sending the commitment matrix C from the prover to the verifier; and
(a)(f) sending a request from the verifier to the prover after the receipt of the commitment matrix C in said step (a)(e), wherein the request comprises at least first and second request states;
wherein said step (b) comprises the substeps of:
(b)(g) on a first request state of the request, (b)(g)(1) the prover sending the square matrix S to the verifier, and (b)(g)(2) the verifier using received matrix S and the masked matrix M to verify the commitment matrix C, if not verifiable, then authentication fails, otherwise go to step (c)(i); and
(b)(h) on a second request state of the request, (b)(h)(1) the prover calculating a same-size, masked key matrix V from the square matrix S and the private key matrix K and sending the masked key matrix V to the verifier, and (b)(h)(2) the verifier using received masked key matrix V and the base matrix N to verify the commitment matrix C, if not verifiable, then authentication fails, otherwise go to step (c)(i); and
wherein said step (c) comprises the substeps of:
(c)(i) determining whether to make another iteration to improve confidence and, if so, returning to step (a)(d) to make an additional iteration, otherwise issuing a pass decision.
A method in a prover of authenticating a prover using same-size square matrices, wherein the prover has a private key matrix K and a base matrix N, wherein the private key matrix K is a square matrix of a predetermined size, and wherein the base matrix N is of the same size as the private key matrix K, and wherein the prover has a masked matrix M, wherein the masked matrix M is of the same size as the base matrix N, the method comprising the steps of: (a) picking a square matrix S of the same size as the private key matrix K; (b) calculating a same-size, commitment matrix C based on the square matrix S and the masked matrix M and sending the commitment matrix C to at least one verifier; (c) receiving a request from the verifier, wherein the request comprises at least first and second request states; (d) on a first request state of the request, sending the square matrix S to the verifier; and (e) on a second request state of the request, calculating a same-size, masked key matrix V from the square matrix S and the private key matrix K and sending the masked key matrix V to the verifier, wherein the prover and verifier are electronic devices.
(a) picking a square matrix S of the same size as the private key matrix K;
(b) calculating a same-size, commitment matrix C based on the square matrix S and the masked matrix M and sending the commitment matrix C to at least one verifier;
(c) receiving a request from the verifier, wherein the request comprises at least first and second request states;
(d) on a first request state of the request, sending the square matrix S to the verifier; and
(e) on a second request state of the request, calculating a same-size, masked key matrix V from the square matrix S and the private key matrix K and sending the masked key matrix V to the verifier, wherein the prover and verifier are electronic devices.
A method according to claim 10 , wherein the masked matrix M is calculated based on the private key matrix K and the base matrix N.
A method according to claim 11 , wherein M=KNK T .
A method according to claim 11 , wherein the masked key matrix V calculated in said step (e) as V=SK.
A method according to claim 10 , wherein the square matrix S picked in said step (a) is a matrix with random entries.
A method according to claim 10 , wherein the calculating of the commitment matrix C in said step (b) calculates the commitment matrix C based on C=SMS T for this iteration.
A method according to claim 10 , wherein the private key matrix K, the base matrix N, the masked matrix M, the square matrix S, the commitment matrix C, and the masked key matrix V have each entry being a binary digit.
A method according to claim 16 , wherein the size of the private key matrix K, the base matrix N, the masked matrix M, the square matrix S, the commitment matrix C, and the masked key matrix V are of no less then about 24Ã24.
A prover device comprising digital logic for performing the steps of claim 10 .
A method in a verifier of deciding whether or not to authenticate a prover using same-size matrices, wherein the prover provides a base matrix N and a masked matrix M, wherein both the base matrix N and the masked matrix M are square matrices of a predetermined size, the method comprising the steps of: (a) receiving a same-size, commitment matrix C from the prover; (b) choosing one of at least first and second request states and sending the chosen request state to the prover; (c) on a first request state of the request, receiving from the prover a same-size, square matrix S and using the square matrix S and the masked matrix M to verify the commitment matrix C; (d) on a second request state of the request, receiving a same-size, masked key matrix V from the prover and using the received masked key matrix V and the base matrix N to verify the commitment matrix C; and (e) if the commitment matrix C is unverifiable, then authentication fails, wherein the prover and verifier are electronic devices.
(a) receiving a same-size, commitment matrix C from the prover;
(b) choosing one of at least first and second request states and sending the chosen request state to the prover;
(c) on a first request state of the request, receiving from the prover a same-size, square matrix S and using the square matrix S and the masked matrix M to verify the commitment matrix C;
(d) on a second request state of the request, receiving a same-size, masked key matrix V from the prover and using the received masked key matrix V and the base matrix N to verify the commitment matrix C; and
(e) if the commitment matrix C is unverifiable, then authentication fails, wherein the prover and verifier are electronic devices.
A method according to claim 19 , further comprising the step of (f) determining whether to make another iteration to improve confidence and, if so, repeating from said step (a), otherwise issuing a pass decision.
A method according to claim 20 , wherein said step (f) of determining whether to make another iteration to improve confidence continues iterations until a count of the iterations reaches a number sufficient to achieve a confidence level desired by the verifier.
A method according to claim 19 , wherein the request sent from the verifier to the prover in said step (c) is unpredictable from the perspective of the prover.
A method according to claim 19 , wherein the verification of the commitment matrix C in said step (c) verifies SMS T =C; and wherein the verification of the commitment matrix C in said step (d) verifies VNV T =C.
wherein the verification of the commitment matrix C in said step (c) verifies SMS T =C; and
wherein the verification of the commitment matrix C in said step (d) verifies VNV T =C.
A method according to claim 19 , wherein the base matrix N, the masked matrix M, the square matrix S, the commitment matrix C, and the masked key matrix V have each entry being a binary one or zero.
A method according to claim 24 , wherein the size of the base matrix N, the masked matrix M, the square matrix S, the commitment matrix C, and the masked key matrix V are of no less then about 24Ã24.
A verifier device comprising a digital logic for performing the steps of claim 19 .
A method of deciding whether or not to authenticate a prover using same-size square matrices, the method comprising the steps of: (a) establishing a private key matrix K, wherein the private key matrix K is a square matrix of a predetermined size; (b) choosing a base matrix N of the same size as the private key matrix K; (c) calculating a same-size, masked matrix M; (d) picking by the prover a same-size, square matrix S for this iteration; (e) calculating by the prover a same-size, commitment matrix C after the picking of the square matrix S in said step (d) and sending the commitment matrix C from the prover to the verifier; (f) sending a request from the verifier to the prover after the receipt of the commitment matrix C in said step (e), wherein the request comprises at least first and second request states; (g) on a first request state of the request, (g)(1) sending the square matrix S from the prover to the verifier, and (g)(2) the verifier using received matrix S and the masked matrix M to verify the commitment matrix C, if not verifiable, then authentication fails, otherwise go to step (i); (h) on a second request state of the request, (h)(1) the prover calculating a same-size, masked key matrix V from the square matrix S and the private key matrix K and sending the masked key matrix V to the verifier, and (h)(2) the verifier using received masked key matrix V and the base matrix N to verify the commitment matrix C, if not verifiable, then authentication fails, otherwise go to step (i); and (i) determining whether to make another iteration to improve confidence and, if so, returning to step (d) to make an additional authentication iteration, otherwise issuing a pass decision, wherein the prover and verifier are electronic devices.
(a) establishing a private key matrix K, wherein the private key matrix K is a square matrix of a predetermined size;
(b) choosing a base matrix N of the same size as the private key matrix K;
(c) calculating a same-size, masked matrix M;
(d) picking by the prover a same-size, square matrix S for this iteration;
(e) calculating by the prover a same-size, commitment matrix C after the picking of the square matrix S in said step (d) and sending the commitment matrix C from the prover to the verifier;
(f) sending a request from the verifier to the prover after the receipt of the commitment matrix C in said step (e), wherein the request comprises at least first and second request states;
(g) on a first request state of the request, (g)(1) sending the square matrix S from the prover to the verifier, and (g)(2) the verifier using received matrix S and the masked matrix M to verify the commitment matrix C, if not verifiable, then authentication fails, otherwise go to step (i);
(h) on a second request state of the request, (h)(1) the prover calculating a same-size, masked key matrix V from the square matrix S and the private key matrix K and sending the masked key matrix V to the verifier, and (h)(2) the verifier using received masked key matrix V and the base matrix N to verify the commitment matrix C, if not verifiable, then authentication fails, otherwise go to step (i); and
(i) determining whether to make another iteration to improve confidence and, if so, returning to step (d) to make an additional authentication iteration, otherwise issuing a pass decision, wherein the prover and verifier are electronic devices.
A method according to claim 27 , wherein said step (i) of determining whether to make another iteration to improve confidence continues iterations until a count of the iterations reaches a number sufficient to achieve a confidence level desired by the verifier.
Ref US20120143830A1: Claims:
A method for analyzing a data stream, the method comprising: receiving, from a prover configured to process the data stream, a first data block and a sibling data block, wherein the first data block and the sibling data block are associated with a first level of a binary tree of hash values; calculating a current hash value using the first data block, the sibling data block, and a first random number; and processing a next level in the binary tree, wherein the processing of the next level in the binary tree comprises: sending, to the prover, a current random number and a request for a sibling hash value, wherein the sibling hash value is a sibling of the current hash value; receiving the sibling hash value; determining a subsequent random number; and calculating a subsequent hash value using the current hash value, the sibling hash value, and the subsequent random number.
receiving, from a prover configured to process the data stream, a first data block and a sibling data block, wherein the first data block and the sibling data block are associated with a first level of a binary tree of hash values;
calculating a current hash value using the first data block, the sibling data block, and a first random number; and
processing a next level in the binary tree, wherein the processing of the next level in the binary tree comprises: sending, to the prover, a current random number and a request for a sibling hash value, wherein the sibling hash value is a sibling of the current hash value; receiving the sibling hash value; determining a subsequent random number; and calculating a subsequent hash value using the current hash value, the sibling hash value, and the subsequent random number.
sending, to the prover, a current random number and a request for a sibling hash value, wherein the sibling hash value is a sibling of the current hash value;
receiving the sibling hash value;
determining a subsequent random number; and
calculating a subsequent hash value using the current hash value, the sibling hash value, and the subsequent random number.
The method of claim 1 , further comprising: determining a calculated root hash value for the binary tree by: recursively
[Truncated to input limit]