Increased confidence in the IC while maintaining the privacy of personal data
This post is the answer to habrahabr.ru/post/244753
To increase confidence and transparency in the IC, you can apply a fairly simple solution described in this post. When a user votes for, against, or withdraws his vote for any initiative, it is necessary for the ROI to generate a special verification code, but not containing the user's personal information. A list of such codes should be available for general use. Thus, everyone could check the result of taking into account his vote in public access. This technical solution is simple, it gives an opportunity to control the counting of votes to some extent and, thus, increases the confidence of citizens in the IC.
Proposed protocol of action.
')
For starters, ROI generates a 2048-bit RSA key-pair (SK, PK) for use as an electronic digital signature (EDS), where is the SK-secret key and PK is the public key. The public key is published in the public domain, and the secret key is stored and used only on the POI server. There may be one such key for the entire IC or many different for different initiatives. For example, you can generate your own separate key for each initiative. Or update the key for the entire ROI from time to time. To identify the key, we will use the concept of “key version” (or index, key number). Additionally, but not necessarily for the first version of the system, the POI can publish the key certificate.
Structure and generation of codes that should be publicly available.
1. When voting by the user, ROI forms the following vector V, 49 bytes long:
Key version (number): 4 bytes
Initiative number: 4 bytes
Event time (UTC time): 8 bytes
Event Type: 1 byte (FOR, AGAINST, FEEDBACK)
Hash voted user, calculated as
H = SHA256 (UserSecret; SNILS; Initiative Number): 32 bytes.
UserSecret is a secret whose source is the user himself. For example, it may be a password for a voice that a user enters on the ROI website when voting. If the POI technically allows, then it can be a password when entering the POI or its hash, in which case the ROI can automatically insert it into the field. In any case, it should be what comes from the user, and what is known to him alone and to no one else. About the reasons for innovation - read the spoiler comments.
2. Further, ROI uses the corresponding secret RSA key SK in order to obtain the second part of the code - a digital signature (EDS):
S = RSA_Sign (SK; V) - the result will be 256 bytes.
3. A pair (V; S) is sent by e-mail to a voted user, and is also placed in public access (for example, in text PEM format).
Pros:
• Any person using the open list of {V; S} pairs can calculate the total number of votes for the selected initiative, having previously verified each Vx value using the ROI public key as follows: RSA_Verify (PK; Sx; Vx) returns “success” or “not success". In essence, the function decrypts the Sx signature using the PK public key and checks the result against Vx, if "success" is equal.
• Anyone on the {V; S} list can find their voting code, since it must be emailed to the user immediately after the vote. If the code is not found in the general list, the user can present his pair (Vx, Sx) as evidence of unrecorded voice. In addition, the user must verify that his own Hx vector from Vx was formed correctly, excluding the possibility of a scenario where the ROI sends the same pair (Vx, Sx) to two users, and takes only one vote into account.
• Third parties will not be able to talk about the unrecorded voice of the Vx without providing the corresponding Sx signature pair, since for this you need to know the secret key of the IC. Thus, the IC is protected from unfounded claims of this kind.
• The H field is added to the V line in order to uniquely identify the actions of the same user within the framework of the selected initiative. For example, the FOR-CANCEL-AGN sequence must be tied to a specific user so that this sequence can be tracked in the {V; S} event list. At the same time, the SNILS of the user itself is inaccessible, since the secret key of the ROI is included in the hash that is generated on the ROI server. According to the hash, it is impossible to know either the secret key or the person's SNILS. And even if the SNILS is known, it is impossible to know the secret key of the ROI by hash. Also, it is impossible to check how this or that person voted, knowing his SNILS, since the connection between SNILS and H is not public information, it is known only to the person who voted, as well as the result of the vote — this information is now sent to the user via email. Thus, this design does not change the current level of security of personal information (as a person voted), and there is no leakage of information on the SNILS or the ROI secret key.
• When presenting a lost voice (Vx, Sx) to a specific user in public access, a connecting pair is created between the voice and a specific person, and then it becomes clear to all how that particular person voted. But now the situation is similar - if I voted and my vote was not taken into account, then, declaring this, I give out publicly information about how I voted. However, the plus is that the lost voice (Vx, Sx) and, thus, the claim to the IC, can be transferred to the public space anonymously, without giving out a connection with a specific user.
Minuses:
• It is impossible to track the scenario in which the ROI can add votes for or against non-existing SNILS. But this scenario is possible now.
Technical implementation:
To implement the idea, the IC can set up OpenSSL (an open and free cryptographic library widely used in many systems as well as establishing encrypted channels in IP connections, browsers and many other applications), and using it from its scripts for all the above operations: generation RSA key (for EDS), signing and SHA256 hashing. Key generation is a slow operation, but rare (once or when opening a new initiative). Signing with a secret key and hashing is a quick operation. OpenSSL can be used either from a command line or a script, or from various compiled programming languages, such as C / C ++. The implementation does not require any infrastructural or other complex steps, and may well fit into several lines of the script or code.
UPD: Updates and additions at the request of readers.
I have a feeling that if all the opinions are folded, then it will be zero. But I'll try:
1. Clarified in the text that the RSA key is generated on the side of the IC for use as a digital signature. Also RSA_Encrypt / RSA_Decrypt were replaced with RSA_Sign / RSA_Verify, respectively.
2. A question was asked why not ECDSA 256 bits (elliptic curve digital signing algorithm). Yes, there are advantages in the size of the digital signature S. There will be not 256 bytes, as in the case of RSA, but 72. But there are also disadvantages in speed. The RSA_Verify operation works many times faster than ECDSA_Sign and Verify. And if we just change RSA_Sign / Verify to RSA_Encrypt / Decrypt and publish SK instead of PK, then we will get a server that can quickly sign, many times faster than ECDSA.
3. Why not GOST? I generally heard about our Soviet standards with an ear of the ear, I just know that some of them were copied from foreign ideas and there was something added a little to make it look different. An example is the GOST cipher created in the KGB (well, I know it by that name in the scientific community), which copies 3DES with slight variations. The same questions according to GOST hash algorithm - I have no idea.
4. Let us, in order to prevent such questions of the Chinese (they have something there too), as in PP.2-3, we can immediately replace it: let the asymmetric algorithm be X, and the hashing algorithm Y, and choose which one you want. Just keep the security level at least 128 bits for the algorithms used (and preferably 256), but otherwise this is a matter of choice and does not greatly affect the essence.
Thank!
To increase confidence and transparency in the IC, you can apply a fairly simple solution described in this post. When a user votes for, against, or withdraws his vote for any initiative, it is necessary for the ROI to generate a special verification code, but not containing the user's personal information. A list of such codes should be available for general use. Thus, everyone could check the result of taking into account his vote in public access. This technical solution is simple, it gives an opportunity to control the counting of votes to some extent and, thus, increases the confidence of citizens in the IC.
Proposed protocol of action.
')
For starters, ROI generates a 2048-bit RSA key-pair (SK, PK) for use as an electronic digital signature (EDS), where is the SK-secret key and PK is the public key. The public key is published in the public domain, and the secret key is stored and used only on the POI server. There may be one such key for the entire IC or many different for different initiatives. For example, you can generate your own separate key for each initiative. Or update the key for the entire ROI from time to time. To identify the key, we will use the concept of “key version” (or index, key number). Additionally, but not necessarily for the first version of the system, the POI can publish the key certificate.
Structure and generation of codes that should be publicly available.
1. When voting by the user, ROI forms the following vector V, 49 bytes long:
Key version (number): 4 bytes
Initiative number: 4 bytes
Event time (UTC time): 8 bytes
Event Type: 1 byte (FOR, AGAINST, FEEDBACK)
Hash voted user, calculated as
H = SHA256 (UserSecret; SNILS; Initiative Number): 32 bytes.
UserSecret is a secret whose source is the user himself. For example, it may be a password for a voice that a user enters on the ROI website when voting. If the POI technically allows, then it can be a password when entering the POI or its hash, in which case the ROI can automatically insert it into the field. In any case, it should be what comes from the user, and what is known to him alone and to no one else. About the reasons for innovation - read the spoiler comments.
UPD: Changes to the first edition, motivation
It was: H = SHA256 (SK; SNILS; Initiative Number): 32 bytes.
As a result of discussions, it became clear that there is a hole in the system. Imagine the following scenario: ROI caches the results and returns them, say, every 5 minutes. Suppose some user has voted, and the correct code (Vx, Sx) is generated and sent to him. Suppose someone else also votes in these 5 minutes, and the ROI can send him not a new code, but the code of the previous user (Vx, Sx). Later, when checking their codes, both users will see that their code is in the statement, but the counter on the ROI will increase only by 1, and it is impossible to verify this. That is, we will get a scenario in which a voice may disappear on the IC. The weak link here is the vector Hx. Therefore, it is necessary that the user himself could verify the correctness of the initial data of this vector, but no one else could. This complicates the system a bit.
Here it should be noted that if a user performs several actions, for example, FOR-RELEASE-VS, then UserSecret should remain unchanged for all these actions, so that in the Hx logs the same for these operations is for one user and the selected initiative. In the case when it is impossible to recall a voice (as it is now on the IC), then this question becomes irrelevant and there is no problem.
Corollary: Now the user needs not only to verify that his code (Vx, Sx) is in the list of paged logs, but also to verify that the unique Hx vector from Vx was formed correctly.
As a result of discussions, it became clear that there is a hole in the system. Imagine the following scenario: ROI caches the results and returns them, say, every 5 minutes. Suppose some user has voted, and the correct code (Vx, Sx) is generated and sent to him. Suppose someone else also votes in these 5 minutes, and the ROI can send him not a new code, but the code of the previous user (Vx, Sx). Later, when checking their codes, both users will see that their code is in the statement, but the counter on the ROI will increase only by 1, and it is impossible to verify this. That is, we will get a scenario in which a voice may disappear on the IC. The weak link here is the vector Hx. Therefore, it is necessary that the user himself could verify the correctness of the initial data of this vector, but no one else could. This complicates the system a bit.
Here it should be noted that if a user performs several actions, for example, FOR-RELEASE-VS, then UserSecret should remain unchanged for all these actions, so that in the Hx logs the same for these operations is for one user and the selected initiative. In the case when it is impossible to recall a voice (as it is now on the IC), then this question becomes irrelevant and there is no problem.
Corollary: Now the user needs not only to verify that his code (Vx, Sx) is in the list of paged logs, but also to verify that the unique Hx vector from Vx was formed correctly.
2. Further, ROI uses the corresponding secret RSA key SK in order to obtain the second part of the code - a digital signature (EDS):
S = RSA_Sign (SK; V) - the result will be 256 bytes.
3. A pair (V; S) is sent by e-mail to a voted user, and is also placed in public access (for example, in text PEM format).
Pros:
• Any person using the open list of {V; S} pairs can calculate the total number of votes for the selected initiative, having previously verified each Vx value using the ROI public key as follows: RSA_Verify (PK; Sx; Vx) returns “success” or “not success". In essence, the function decrypts the Sx signature using the PK public key and checks the result against Vx, if "success" is equal.
• Anyone on the {V; S} list can find their voting code, since it must be emailed to the user immediately after the vote. If the code is not found in the general list, the user can present his pair (Vx, Sx) as evidence of unrecorded voice. In addition, the user must verify that his own Hx vector from Vx was formed correctly, excluding the possibility of a scenario where the ROI sends the same pair (Vx, Sx) to two users, and takes only one vote into account.
• Third parties will not be able to talk about the unrecorded voice of the Vx without providing the corresponding Sx signature pair, since for this you need to know the secret key of the IC. Thus, the IC is protected from unfounded claims of this kind.
• The H field is added to the V line in order to uniquely identify the actions of the same user within the framework of the selected initiative. For example, the FOR-CANCEL-AGN sequence must be tied to a specific user so that this sequence can be tracked in the {V; S} event list. At the same time, the SNILS of the user itself is inaccessible, since the secret key of the ROI is included in the hash that is generated on the ROI server. According to the hash, it is impossible to know either the secret key or the person's SNILS. And even if the SNILS is known, it is impossible to know the secret key of the ROI by hash. Also, it is impossible to check how this or that person voted, knowing his SNILS, since the connection between SNILS and H is not public information, it is known only to the person who voted, as well as the result of the vote — this information is now sent to the user via email. Thus, this design does not change the current level of security of personal information (as a person voted), and there is no leakage of information on the SNILS or the ROI secret key.
• When presenting a lost voice (Vx, Sx) to a specific user in public access, a connecting pair is created between the voice and a specific person, and then it becomes clear to all how that particular person voted. But now the situation is similar - if I voted and my vote was not taken into account, then, declaring this, I give out publicly information about how I voted. However, the plus is that the lost voice (Vx, Sx) and, thus, the claim to the IC, can be transferred to the public space anonymously, without giving out a connection with a specific user.
Minuses:
• It is impossible to track the scenario in which the ROI can add votes for or against non-existing SNILS. But this scenario is possible now.
Technical implementation:
To implement the idea, the IC can set up OpenSSL (an open and free cryptographic library widely used in many systems as well as establishing encrypted channels in IP connections, browsers and many other applications), and using it from its scripts for all the above operations: generation RSA key (for EDS), signing and SHA256 hashing. Key generation is a slow operation, but rare (once or when opening a new initiative). Signing with a secret key and hashing is a quick operation. OpenSSL can be used either from a command line or a script, or from various compiled programming languages, such as C / C ++. The implementation does not require any infrastructural or other complex steps, and may well fit into several lines of the script or code.
UPD: Updates and additions at the request of readers.
I have a feeling that if all the opinions are folded, then it will be zero. But I'll try:
1. Clarified in the text that the RSA key is generated on the side of the IC for use as a digital signature. Also RSA_Encrypt / RSA_Decrypt were replaced with RSA_Sign / RSA_Verify, respectively.
2. A question was asked why not ECDSA 256 bits (elliptic curve digital signing algorithm). Yes, there are advantages in the size of the digital signature S. There will be not 256 bytes, as in the case of RSA, but 72. But there are also disadvantages in speed. The RSA_Verify operation works many times faster than ECDSA_Sign and Verify. And if we just change RSA_Sign / Verify to RSA_Encrypt / Decrypt and publish SK instead of PK, then we will get a server that can quickly sign, many times faster than ECDSA.
3. Why not GOST? I generally heard about our Soviet standards with an ear of the ear, I just know that some of them were copied from foreign ideas and there was something added a little to make it look different. An example is the GOST cipher created in the KGB (well, I know it by that name in the scientific community), which copies 3DES with slight variations. The same questions according to GOST hash algorithm - I have no idea.
4. Let us, in order to prevent such questions of the Chinese (they have something there too), as in PP.2-3, we can immediately replace it: let the asymmetric algorithm be X, and the hashing algorithm Y, and choose which one you want. Just keep the security level at least 128 bits for the algorithms used (and preferably 256), but otherwise this is a matter of choice and does not greatly affect the essence.
Thank!
Source: https://habr.com/ru/post/245017/
All Articles