Patent Application
20250119298
The present disclosure relates to post-quantum cryptography (PQC), particularly it specifies a cryptographic process for generating digital signature which is quantum safe.
Quantum computing is a type of computing that uses quantum mechanics, a branch of physics, to store and process information. Unlike classical computers that use bits to represent information as either 0 or 1, quantum computers use quantum bits or qubits, which can represent a 0, 1, or both simultaneously, allowing for much faster processing. This makes quantum computers particularly useful for solving certain problems that classical computers struggle with, such as encryption, optimization, and simulation.
Quantum computing is widely said to be the future of computing as we know it-one that could allow human kind to perform extremely complex computations very fast that are simply impossible using today's computing technologies. The existing systems are based on the assumption that factoring large integers is computationally intractable. However, there exist algorithms which show that factoring large integers is efficient on an ideal quantum computer. Existing technologies rely heavily on cryptographic techniques like digital signatures for digital security. Hence, quantum attacks could break these cryptographic algorithms and consequently the integrity and reliability of technologies will be compromised.
For 20 years scientists and engineers have been saying that “someday” they'll build a full-fledged quantum computer able to perform useful calculations that would overwhelm any conventional supercomputer.
Currently there are various organizations in race to develop the first fully functional quantum computer. IBM is one of the leading organizations currently developing the quantum computers. IBM made its aspirations more concrete by publicly announcing a “road map” for the development of its quantum computers, including the ambitious goal of building one containing 1000 qubits by 2023. IBM's current largest quantum computer, Osprey, revealed this month, contains 433 qubits. Right now, Google's Sycamore computer has about 53 working qubits.
A Canadian company called DWAVE has a quantum computer with 512 qubits, but it has very high error rates on its qubits and is based on another principle called quantum annealing. To run Shor's on 2048-bit RSA would require at least 10,000 qubits. It will probably be a while before such a machine can be built.
An alternative cryptographic technology that do not rely on computational complexity is a need of the hour to prevent quantum attacks. The proposed invention presents a cryptographical method which is based on information security, hence making it quantum safe.
The present invention provides a system for creation and verification of digital signature which is quantum safe. The invention comprises of four steps:
The proposed method is based on the classical cryptographic method of Shamir's secret sharing which is used to share a secret amongst n users so that at least k users need to come together to recreate the secret. This method is based on information-security which means that the security of the method does not rely on complicated calculation but on the availability of information.
The encryption scheme derived in the proposed method is also based on a multi-key variant of homomorphic encryption (MKHE) using the BFV scheme. This method depends on the cryptographic hardness of ring-learning with errors (R-LWE).
The proposed method has a signer-verifier setup which works using the I-AM® Crypto-ID. There are two participating users-one who signs a document and the other verifies the signature, who interact between each other through the Pi platform through a secured channel of communication that is established by a QUANTUM SAFE I-AM® CI2 key exchange protocol. The verifier uses a zero-knowledge-proof which means that, during the process, the user can verify the signer's ownership without using any of the signer's private information, hence ensuring a cryptographically secure process.
To initiate the process both Verifier and Signer run the I-AM®-CIϕ handshake with Pi-Control™ Platform and generate the secret keys KA and KB respectively. In the next step, Signer & Verifier run the I-AM®-CI2 Identity Based Authenticated Key Agreement Protocol in order to generate the symmetric key KAB. This shared secret key is called as the collective identity.
In an implementation a quantum safe method for creation and verification of digital signature is disclosed. The method comprises encrypting 202, a plurality of shares associated with a User A 104, by using an encryption scheme to obtain encrypted plurality of shares. Passing 204, the plurality of encrypted shares associated with the User A 104, to the platform 102. Re-encrypting 206, the plurality of the shares to obtain the encrypted plurality of shares by the platform 102. The method further comprises decrypting 208, the plurality of shares shared by the User B 106. Receiving 210, the plurality of shares associated with the User B 106 from the User B 106 by the User A 104. Sharing 212, by the platform 102, half of the plurality of shares encrypted for the User A 104, with the User A 104 and the other half of the plurality of shares encrypted for the User B 106, with User B 106. Further independently combining 214, by the User A 104, the plurality of shares associated with the User A 104 with the plurality of shares associated with the User B 106, received from the User B 106. Independently combining 216, by the User B 106, the plurality of shares associated with the User B 106 with the plurality of shares associated with the User A 104, received from the User A 104. Further re-creating 218, the same secret key which is the “collective identity” for the User A 104 and the User B 106 in context. Creating 220, the collective ID between the User A and the User B to enable establishing secure communication between the user A, the User B, and the platform 102.
The detailed description is described with reference to the accompanying figures. In the figures, the left-most digit(s) of a reference number identifies the figure in which the reference number first appears. The same numbers are used throughout the drawings to refer like features and components.
Some embodiments of the present disclosure, illustrating all its features, will now be discussed in detail. It must also be noted that as used herein and in the appended claims, the singular forms “a”, “an” and “the” include plural references unless the context clearly dictates otherwise. Although any systems and methods similar or equivalent to those described herein can be used for creation and verification of digital signature which is quantum safe, i.e., the digital signature cannot be hacked or accessed using a quantum computing system or conventional computing system without the access rights.
Further a Pi-Control™ Platform as disclosed in the present disclosure may refer to a centralized or distributed platform that may be hosted on a server, or a remote server, or a cloud server. Further in present disclosure the Pi-Control™ Platform may be interchangeably referred as the platform.
An I-AM® Crypto-ID as disclosed in the present disclosure may refer to unique identification created, generated, and/or assigned by the platform to user or users accessing the platform. Further the I-AM® Crypto-ID may refer to KA for a User A, and KB for User B.
An I-AM®-CIϕ handshake as disclosed in the present disclosure may refer to a secured, and encrypted communication between the users and the platform. The secured, and the encrypted communication may be configured to transpire over known communication protocol like 802.11 (Wi-Fi), 802.15 (including Bluetooth™), 802.16 (Wi-Max), 802.22, Cellular standards such as CDMA, CDMA2000, WCDMA, 5G, Radio Frequency (e.g., RFID), Infrared, laser, Near Field Magnetics, Ethernet, Internet etc.
The present disclosure in an aspect may disclose a system and a method that is post-quantum safe as the security relies on the mathematical hardness of ring-learning with error (R-LWE) and the complexity of solving a shortest vector problem. Further the system and method may be configured to implement an information-security protocol under the R-LWE concept.
Further in another aspect the system and the method is based on the concept of multi-key homomorphic encryption which relies on arithmetic operations between ciphertexts created by multiple keys which can be decrypted by multiple users using their individual secret keys without sharing any private information apriori.
Further in another aspect, the notion of verifiability of the public information of users may be included to ensure reliability within the zero-trust environment of Pi-Control™, ie a user should be able to verify that the public information of another user he is communicating with has not been compromised by a dishonest server.
Further in another aspect the system and the method may be configured to conduct all exchange of information between the users and platform using zero-knowledge proof protocol. The zero-knowledge proof protocol may be configured to enable the users to interact with the platform without the need to share any private information.
The Zero-Knowledge Proof protocol relies on proving that something is true without revealing any other information. Zero-knowledge proof protocol comprises a prover who wants to convince a verifier that some statement is true without revealing any other information, e.g., verifier learns that the prover has more than X in his bank account but nothing else (i.e., the actual amount is not disclosed). Thus, the method as disclosed in the present aspect does not provide any private information to be stored in the platform and hence preventing any sort of data breach from the server's end.
The zero-knowledge proof protocol is associated with at least three attributes completeness, Soundness, and Zero-knowledge. The attribute completeness relates to a prover to convince a verifier. Further the attribute soundness relates to a cheater not being able to convince a verifier. The attribute Zero-knowledge further relates to interaction that reveal if a statement is true and nothing else.
In another aspect of the system and the method as disclosed a pseudorandom security is maintained since the public keys are randomly generated every time, hence they act as ephemeral keys.
Further during the creation of shared secret key between two users all information exchange happens through the secured channel created between a user and the platform hence only registered users can create a shared secret key.
The classical security describes the difficulty of breaking a cryptosystem using classical computation systems. The quantum security describes the difficulty of breaking a cryptosystem using quantum computers.
The traditional cryptographic protocols provide classical security as there are no known methods exist to break them using classical computers. But there are quantum algorithms (Shor's Algorithm) that can use Quantum Computers to break these cryptosystems.
The cryptosystems used in the embodiment provides both classical & quantum security. That means the cryptographic protocols of Pi-Control™ Platform can neither be breakable using classical system not by quantum systems.
The proposed method is based on the classical cryptographic method of Shamir's secret sharing which is used to share a secret amongst n users so that at least k users need to come together to recreate the secret. For e.g., if a key code is to be shared with 10 users, then at least 6 users need to connect to enable sharing of the key code. This method is based on information-security which means that the security of the method does not rely on complicated calculation but on the availability of information.
The ring-LWE is a family of problems given by the following parameters:
The main attraction of R-LWE is their worst-case hardness theorem which essentially says that solving certain instantiations is at least as hard as quantumly solving an approximate shortest vector problem (approx-SVP) on any ideal lattice, ie a lattice corresponding to an ideal of a ring.
The proposed method also relies on the ring-LWE hardness based on lattice which has been considered as one of the alternative approaches in post-quantum cryptography.
Further the method uses a fully homomorphic public key encryption (FHE) system where the addition of ciphertexts hold true, ie Enc(m1, sk1)+Enc(m2, sk2)=Enc(m1+m2, sk1+sk2). In single-key FHE, the ciphertext is decrypted by each user using a joint secret key which is problematic in a multi-user scenario. The notion of multi-key homomorphic encryption (MKHE) allows each user to partially decrypt the new ciphertext with his own secret key to retrieve the actual message. This is used to define a key-exchange protocol between two registered users under the Pi-Control™ platform.
The proposed method also has a signer-verifier setup which works using the shared secret key. In accordance with the system and method as disclosed there may be at least two participating users-one who signs a document and the other verifies the signature. Further the at least two users interact between each other through the Pi-Control™ platform through a secured channel of communication. The verifier uses a zero-knowledge-proof which means that, during the process, the user can verify the signer's ownership without using any of the signer's private information, hence ensuring a cryptographically secure process.
Referring to
Further in accordance with the exemplary embodiment, the communication between the at least one first user A 104, and the at least one user B 106 may be possible via the platform server 102. For ease of disclosure the at least one first user A 104 may be represented as User A. Further for ease of disclosure the at least one second user B 106 may be represented as User B. The communication between the server 102, and the User A 104, and/or User B 106, may be via the secured and encrypted network.
The network may be configured to use a CTR-based AES256 encryption. Further the AES256 encryption is provided with a salted hash to the shared key with HMAC-SHA256, thereby adding a cryptographically secure random number (nonce) to the key each time preventing the possibility of key re-use.
Further in an aspect of the present disclosure a key encapsulation mechanism to build a secure communication channel between two registered users is disclosed. Further the public key encryption scheme of ring learning with errors (ring-LWE) prevents any information being shared with the Pi-control server during the key exchange process.
In accordance with the system the Verifier and Signer are configured to run a handshake or connect with the platform 102 and generate the secret keys KA and KB respectively, i.e., User A 104 may be verifier, and User B 106 may be signer. Further User A 104 and the User B 106 may be configured to run the Identity Based Authenticated Key Agreement Protocol in order to generate the symmetric key KAB. This shared secret key is called as the collective identity.
Further in accordance with the exemplary implementation of the present disclosure the system 100 may initiate by creating the individual id for the two users, User A 104 and User B 106 through the handshake. After the handshaking, the platform 102 acquires the information which can be used to generate the individual id for the signer 104 and the verifier 106.
The system 100, in accordance with the present disclosure each of the users 104, and 106 and the platform 102 generates a cryptographically secure pseudo random number. This number may be split into a plurality of shares using the Shamir's secret sharing protocol with a certain number of user and threshold values.
The server 102, hosting the platform 102, may comprise at least one processor, at least one memory, and at least one module, configured to process, store, execute the instructions, the encryption-decryption algorithm, and other instructions and algorithm as disclosed in the exemplary embodiments.
Further User A, and the User B may be configured to access the platform/server 102, using a device or devices having at least one processor, at least one memory, and at least one module, configured to process, store, execute the instructions, the encryption-decryption algorithm, and other instructions and algorithm as disclosed in the exemplary embodiments.
The User A 104, the User B 106, and the platform 102 may undergo a key distribution mechanism. User A 104 may take half of his shares and sends it to the verifier, i.e., User B 106 through the secured channel created by the platform 102 in the way as illustrated in
Further the at step 204, passing the plurality of encrypted shares associated with the User A 104, to the platform 102. Further the platform 102, may be configured to decrypt the plurality of encrypted shares, using the same key to decrypt and encrypt.
The platform 102 may be configured to have the required information to generate the unique identity for the registered user A from the handshake. Further at step 206 re-encrypting the plurality of the shares to obtain the encrypted plurality of shares by the platform 102. The re-encryption of the plurality of shares may be performed by the platform 102 to be passed to the User B 106.
Further in accordance with the system 100, at step 208, decrypting the plurality of shared by the User B 106. Further the platform 102, at step 210, receiving the plurality of shares associated with the User B 106 from the User B 106 by the User A 104. Further the sharing of the plurality of shares between User B 106 and the User A 104 using the secured channel created by the platform 102.
In step 212, sharing by the platform 102, half of the plurality of shares encrypted for the User A 104, with the User A 104 and the other half of the plurality of shares encrypted for the User B 106, with User B 106. At step 214, independently combining by the User A 104, the plurality of shares associated with the User A 104 with the plurality of shares associated with the User B 106, received from the User B 106. Further at step 216, independently combining by the User B 106, the plurality of shares associated with the User B 106 with the plurality of shares associated with the User A 104, received from the User A 104. In accordance with the aspect of the embodiment for the actual key exchange, the User A, and the User B again exchange one share with each other through the secured channel of the platform 102.
Further in accordance with the embodiment, at step 218, re-creating the same secret key which is the “collective identity” for the User A 104 and the User B 106 in context. The re-creating of the key is enabled using the shared information and the previously combined information, by the concept of Shamir secret sharing.
At step 220, creating the collective ID between the User A and the User B to enable establishing secure communication between the user A, the User B, and the platform 102.
a. QUANTUM SAFE I-AM® CI2-MKHE Based
In another exemplary implementation of the present embodiments a concept of Learning with errors on a ring structure (ring-LWE) is disclosed. In the present invention, a key encapsulation is done using ring-LWE to securely exchange information between two users, A and B, who have been registered under I-AM® and obtained valid crypto ids a priori.
Referring to Table 1 illustrates a technical flow of key exchange between two registered users using MKHE, in accordance with an exemplary embodiment of the present disclosure. Further
The method as disclosed in accordance with the exemplary embodiment, at step 302, creating or generating by the platform 102, a unique key KA for the User A 104, and another unique key KB for the User B 106. The unique key KA for the User A 104 may be an encrypted key, and another unique key KB for the User B 106 may be an encrypted key.
Further at step 304, an implementation may be initiated by each user i.e., User A and User B generating a public key pair (pkA, skA) and (pkB, skB) based on ring-LWE parameters.
Further at step 306, splitting a randomly generated cryptographically secure pseudo random number SA associated with User A 104, into a plurality of shares [a1, a2, a3, a4 . . . an]. Further the splitting of the randomly generated cryptographically secure pseudo random number SA into the plurality of shares [a1, a2, a3, a4 . . . an] may be based on a threshold value. For e.g., SA is split using a (3,4) threshold (n=2*(3−1), k=3) and the shares are taken as [a1, a2, a3, a4]. Further for the ease of explanation [a1, a2, a3, a4 . . . an] may be interchangeably be represented as [a1, a2, a3, a4].
Further at 308, splitting a randomly generated cryptographically secure pseudo random number Sp associated with User B 106, into a plurality of shares [b1, b2, b3, b4 . . . bn]. Further the splitting of the randomly generated cryptographically secure pseudo random number SB into the plurality of shares [b1, b2, b3, b4 . . . bn] may be based on a threshold value. For e.g., SB is split using a (3, 4) threshold (n=2*(3−1), k=3) and the shares are taken as [b1, b2, b3, b4]. Further for the ease of explanation [b1, b2, b3, b4 . . . bn] may be interchangeably be represented as [b1, b2, b3, b4].
At step 310, splitting a randomly generated cryptographically secure pseudo random number SG associated with the platform 102, into a plurality of shares [g1, g2, g3, g4 . . . gn]. Further the splitting of the randomly generated cryptographically secure pseudo random number SG into the plurality of shares [g1, g2, g3, g4 . . . gn] may be based on a threshold value. For e.g., SG is split using a (3,4) threshold (n=2*(3−1), k=3) and the shares are taken as [g1, g2, g3, g4]. Further for the ease of explanation [g1, g2, g3, g4 . . . gn] may be interchangeably be represented as [g1, g2, g3, g4].
In an aspect of the exemplary embodiment, the step 306, 308, 310 may be performed at least partially simultaneously at the respective server/devices. In another aspect the step 306, 308, 310 may be performed consecutively at the respective server/devices. In yet another aspect the step 306, 308, 310 may be performed consecutively with at least partial overlap between the steps 306, 308, 310 at the respective server/device. Further sequence of the steps 306, 308, 310 being performed may be changed.
Further in accordance with the exemplary embodiment at step 312, sharing by the User A 104 to the platform 102, at least partial shares [a1, a2] and [a3, a4] from the plurality of shares [a1, a2, a3, a4 . . . an] after homomorphically encrypting using the public key, pkA of User A 104. Further at step 314, simultaneously sharing by the User B 106 to the platform 102, at least partial shares [b1, b2] and [b3, b4] from the plurality of shares [b1, b2, b3, b4 . . . bn] after homomorphically encrypting using the public key, pkB of User B 106. The users are configured to share the shares by encrypting with their own public keys, ie A1=HEnc([a1, a2], pkA), A2=HEnc([a3, a4], pkA), B1=HEnc([b1, b2], pkB), B2=HEnc([b3, b4], pkB) hence keeping them oblivious to the platform 102.
In accordance with the exemplary embodiment to establish a secured connection between the user A, and the user B, at step 316, receiving by the platform 102, from the User A at least encrypted partial shares A1 and from the User B at least encrypted partial shares B1, the platform 102 performs a homomorphic addition of ciphertexts. Then the platform 102 performs a plaintext and ciphertext addition with its partial shares [g1, g2] to obtain S1=A1+B1+[g1, g2].
At step 318, receiving by the platform 102, from the User A at least encrypted partial shares A2 and from the User B at least encrypted partial shares B2, the platform 102 performs a homomorphic addition of ciphertexts. Then the platform 102 performs a plaintext and ciphertext addition with its partial shares [g3, g4] to obtain S2=A2+B2+[g3, g4].
At step 320, receiving from the platform 102, the User B 106 partially decrypts the encrypted sum S1 with his secret key skB and the ciphertext A1, where partial decryption pdB=S1[0]+skB. S1[1]−skB. A1[1]. Further in step 324, shares PDB=HEnc(pdB, pkA) with the User A 104 via the platform 102 after re-encrypting it with the public key pkA of User A 104.
Further in step 328, the User A 104 will decrypt the partially decrypted information by PDB[0]+skA. PDB[1]−u1·pkA to obtain the sum of shares as [z1, z2]=[a1+b1+g1, a2+b2+g2].
In a simultaneous instance, At step 322, receiving from the platform 102, the User A 104 partially decrypts the encrypted sum S2 with his secret key sky and the ciphertext B2, where partial decryption pdA=S2[0]+skA. S2[1]−skA. B2[1]. Further in step 326, shares PDA=HEnc(pdA, pkB) with the User B 106 via the platform 102 after re-encrypting it with the public key pkA of User B 106.
Further in step 330, the User B 106 will decrypt the partially decrypted information by PDA[0]+skB. PDA[1]−v2·pkB to obtain the sum of shares as [z3, z4]=[a3+b3+g3, a4+b4+g4].
The exemplary embodiment may be further configured at step 332, for sharing via the platform 102, z2 to User B 106, and z3 to User A 104. Further at step 334, reconstructing keys KAB by the User A, and the User B independent of each other. The keys KAB can be re-constructed by using z1, z2, z3, User A 104 can reconstruct to get the secret KAB=SA+SB+SG and using z2, z3, z4, User B 106 can reconstruct to get the same secret KAB=SA+SB+SG.
b. Encryption Scheme
In accordance with the exemplary embodiment, an encryption scheme deployed by the platform 102, may be symmetric encryption, i.e., the same key may be used for encryption and decryption. For ease of the disclosure User A may be interchangeably be referred as encryptor. Further for ease of the disclosure User B may be interchangeably be referred as decryptor.
The encryptor takes the id and produces an HMAC-SHA256 hash using a salt S. This is used to generate an AES256 key for encrypting the message. This message along with the salt S is sent as a cipher to the decryptor.
The decryptor takes the same id and produces an HMAC-SHA256 hash using the same salt S. He can generate the same AES256 key and decrypt successfully.
The encryptor and decryptor should have the same id available through handshaking. The encryption scheme is based on CTR based AES-256. In the process of key distribution and key exchange, all communications between the user and the Pi-platform happens through the secured channel established using the I-AM crypto ID. To generate the AES key, the crypto-ID can be used as a seed as both the user and the platform will have the I-AM Crypto ID. This means that, for every encryption between the user and the platform, the same AES key gets generated. This will create a security problem due to key re-use. To avoid this:
A random salt, T is added to the I-AM Crypto-ID, say KA
This seed can be used to generate the AES-256 key for a single instance of encryption.
The salt, T is shared along with the encrypted information. This solves the key re-use issue as each time the seed gets randomized using a new salt.
c. QUANTUM SAFE I-AM® CI2—Digital Signature
The Table 2, illustrates a technical flow to represent the signer/verifier protocol deployed by the platform 102. In accordance with the exemplary embodiment, the User A may be referred as ‘signer’, the User B may be referred as ‘verifier’, and KAB is the “collective id” generated during key exchange. Further
The method as disclosed in accordance with the exemplary embodiment, at step 402, creating or generating by the platform 102, a unique key KA for the User A 104, and another unique key KB for the User B 106 and a shared secret key KAB between the users.
At step 404, the verifier B shares the HMAC-SHA512 hash of his I-AM®-Crypto id, KB encrypted with the shared secret KAB, via the platform 102. Further in step 506 the signer A decrypts with the shared secret KAB to get the hash of the verifier's id.
Further at step 408, signer A adds his own I-AM®-Crypto id KA to it and creates a re-hash S with HMAC-SHA512 which he shares with the verifier B via the platform 102.
Further in step 410, the re-hash S is added to the document/message to be signed and a new HMAC-SHA512 hash T is created. This hash is encrypted with collective id KAB of the signer-verifier and shared with the verifier via the platform 102.
In accordance with the exemplary embodiment to verify the signature, in step 412, the verifier B adds the shared re-hash S to his version of the document/message and validate against the decrypted hash T as receiving from the signer A.
The exemplary embodiment may be configured so that, during the entire process of signing and verification, the information that is shared between A and B is masked efficiently by using randomized salt elements which reduces collision as well as dictionary type attacks.
The foregoing descriptions of specific embodiments of the present disclosure have been presented for purposes of illustration and description. They are not intended to be exhaustive or to limit the present disclosure to the precise forms disclosed, and obviously many modifications and variations are possible in light of the above teaching. The embodiments were chosen and described in order to best explain the principles of the present disclosure and its practical application, to thereby enable others skilled in the art to best utilize the present disclosure and various embodiments with various modifications as are suited to the particular use contemplated. It is understood that various omission and substitutions of equivalents are contemplated as circumstance may suggest or render expedient, but such are intended to cover the application or implementation without departing from the scope of the present disclosure.
| Number | Date | Country | Kind |
|---|---|---|---|
| 202321066705 | Oct 2023 | IN | national |
