Method and system for cryptographic verification of Vox Signata publications

Claims

1. A method for cryptographic verification of digital publications, characterized in that it includes the following stages: record the publication details on the server, including at least the platform cryptographic identifier, the author identifier, the author's public key, the timestamp, and the publication body; perform normalization of the publication body, including converting the text to the canonical Unicode NFC form; send to the client a draft string for calculating the digital fingerprint, formed by concatenating at least the cryptographic platform identifier, the author identifier, the author's public key, the timestamp, the normalized body of the publication, and the root hash of the last private block of the Merkle tree (Last_Merkle_Root); receive from the client confirmation of the specified string and the client fingerprint F_client, calculated by the client locally by cryptographically hashing the string; verify F_client on the server by comparing it with the server fingerprint F_server calculated from the same line, and if there is a match, approve the digital fingerprint F = F_client = F_server, and if there is a discrepancy, reject the publication; forming a short verification identifier (shortID) by extracting the first L characters of the hexadecimal or Base64URL representation of the digital fingerprint F, where L is selected from 16 to 32, checking the uniqueness of the shortID within the platform using atomic insertion with a uniqueness constraint, and if a collision is detected, incrementing L by one with a repeated check; generate a publication address (URL) containing the domain name or IP address of the server and shortID, additionally generate a canonical publication address (canonicalUrl) containing the specified domain name or IP address and the full digital fingerprint F in hexadecimal or Base64URL representation, and additionally generate a publication address in the format vox: / / {shortID}, not tied to a specific network address; generate a platform signature (Sign_Platform) by asymmetrically cryptographically signing a string including F, shortID and URL, using the platform's private key; when using the author's electronic signature, a second transmission is additionally performed, in which the server sends to the client a string for signing, including the normalized body, F, the generated URL and Sign_Platform, and the client calculates the electronic signature of the specified string using its private key and transmits it to the server, after which the server verifies the signature using the author's public key and, if verification is successful, stores it in machine-readable metadata as the author's signature Sig_Author in addition to the digital fingerprint F, while shortID and URL are formed exclusively from the digital fingerprint F, and not from Sig_Author; store in the machine-readable metadata of the web page (JSON-LD) at least: the full digital fingerprint F, both URLs, the length of the shortID L, the hashing algorithm, the cryptographic identifier of the platform, the identifier of the author, the public key of the author, the timestamp, the normalized body of the publication, Last_Merkle_Root, the client fingerprint F_client, the platform signature Sign_Platform, the canonical name of the file corresponding to the shortID with the extension .html, and the proof of inclusion in the Merkle tree (Merkle Proof), containing the ordinal number of the publication in the tree (leafIndex), an array of intermediate hashes (siblings), the root hash (merkleRoot), the number of the hash block (blockIndex) and the hash of the hash block (blockHash); if the author has a qualified electronic signature (QES), a line is generated for signing, including the normalized body of the publication, F, URL, Sign_Platform and, optionally, the hash of the author's biometric sample (Bio_Hash), calculated by the client locally without transmitting biometric data to the server, the QES is calculated from the specified line using the author's protected media and saved in the metadata as the last element; perform client-side verification of the publication's authenticity without accessing the server for a reference value, by extracting the shortID from the URL and determining its length L, extracting the platform's cryptographic identifier, the author's identifier, the author's public key, the timestamp, the normalized body, and Last_Merkle_Root from the page, calculating the fingerprint F' using the same algorithm that was used to create the publication, comparing the first L characters of the representation of F' with the shortID from the URL, and, if they match, concluding that the publication is intact; additionally, the inclusion of the publication in the Merkle tree is checked using the inclusion proof (Merkle Proof), for which the merkleProof fields containing leafIndex, the siblings array, and merkleRoot are extracted from the machine-readable metadata, H_current is initialized with the value of the publication hash F, H_current is sequentially calculated using siblings in the order determined by the leafIndex bits, and the obtained root M_root_computed is compared with merkleRoot and Last_Merkle_Root, whereby the coincidence of all three values ​​confirms that the publication is indeed included in the Merkle tree with the given root, and that Last_Merkle_Root has not been replaced; verify Sign_Platform using the platform's public key, if the author's signature Sig_Author is present, extract it from the metadata and verify it using the author's public key, if the CEP is present, extract it as the last element of the metadata and verify it using the author's public key, and compare the file name of the saved page with the canonical name from the metadata.

2. A system for cryptographic verification of digital publications, characterized in that it contains: a signing server configured to record publication details, normalize the body, send a string to the client of the project for calculating the fingerprint, verify the client fingerprint F_client, calculate the digital fingerprint F, generate a shortID and URL, save machine-readable metadata including proof of inclusion in the Merkle tree (Merkle Proof), generate a platform signature (Sign_Platform) and initiate the procedure for applying a qualified electronic signature (QES); a storage server configured to store web pages of publications and return them by shortID or full fingerprint F, wherein the web page is returned with a Content-Disposition header containing the canonical file name in the format [shortID].html; wherein the storage server is configured to provide web pages of publications through multiple mirror gateways, as well as to transmit pages of publications via peer-to-peer content distribution protocols; a client verification module configured to locally calculate F_client, display a string for visual inspection, send a confirmation to the server, and to extract shortID from the URL, determine its length L, extract details from the page, recalculate the control fingerprint F' and compare the first L characters of F' with shortID, verify Merkle Proof by reconstructing the root of the Merkle tree from leafIndex, siblings and the publication hash F and comparing the obtained root with merkleRoot and Last_Merkle_Root, and verify the signatures Sign_Platform and Sig_Author / CEP without accessing the server for a reference value; a means of constructing a Merkle tree and storing the root hash in an external registry, where the root hash of the last private block (Last_Merkle_Root) is included in the string for calculating the digital fingerprint of each publication; a means of multiple trust anchoring that includes the publication of the platform's cryptographic parameters in a printed publication with a mandatory copy, a notarized document, and / or a public distributed ledger.

3. The system according to claim 2, characterized in that it additionally contains a post-quantum migration tool, configured with the capability of hybrid hashing for new publications and signing migration service records with a post-quantum platform key for previously created publications.

4. The system according to paragraph 2, characterized in that it additionally contains a means of anonymizing publications with the maintenance of a secure audit table of “golden records,” configured with the ability to create a new publication with an anonymous author identifier and post a notification of the fact of anonymization to the original address with cryptographic confirmation of the existence of the original publication, wherein the connection between the original and anonymous author identifiers is saved in the form of a “golden record,” signed with the cryptographic key of the platform.

5. The system according to paragraph 2, characterized in that it additionally contains a means for generating obligation cards with an optimistic version locking mechanism and idempotent payment keys, wherein the obligation card is integrated with payment systems via an API using tokenization of payment instruments and hardware security modules (HSM) for signing payment requests.

6. The method according to paragraph 1, characterized in that the digital fingerprint F is formed by cryptographic hashing, wherein F = HASH(Crypto_ID_Platform + Author_ID + Author_Public_Key + Timestamp + Normalized_Body + Last_Merkle_Root), shortID = hex(F)[0:L], where Author_Public_Key is the public key of the author, and L is the length of shortID determined when creating the publication.

7. The method according to claim 1, characterized in that the normalization further includes converting the line feed characters to a single U+000A (LF) form, replacing sequences of more than two line feed characters with two line feed characters, replacing all whitespace characters that are not line feed characters with a single U+0020 space, and replacing sequences of the resulting spaces with a single space.

8. The method according to claim 1, characterized in that when using the author's electronic signature, the Sig_Author signature is formed by asymmetric signing with two sendings, wherein in the first sending the server receives F_client calculated by the client by hashing, and in the second sending, after generating shortID, URL and Sign_Platform, the server sends to the client a string for signing, including the normalized body, F, URL and Sign_Platform, the client calculates the electronic signature of the specified string using its private key and sends it to the server, after which the server verifies the signature and stores it as Sig_Author in machine-readable metadata in addition to F, wherein Sig_Author = SIGN(User_Private_Key, Normalized_Body + F + URL + Sign_Platform), and shortID = hex(F)[0:L].

9. The method according to paragraph 1, characterized in that the cryptographic identifier of the platform is a cryptographic hash of the initial public key of the platform and the metadata of the genesis record in the key chain, wherein the platform is configured to rotate keys by publishing a new public key signed by the current private key, with recording in a distributed registry or printed publication, without changing the cryptographic identifier of the platform.

10. The method according to claim 1, characterized in that Last_Merkle_Root is the root hash of the last closed hash block constructed on the basis of the Merkle tree from the hashes of publications for the elapsed period, wherein each hash block contains the hash of the previous block.

11. The method according to paragraph 1, characterized in that a cryptographic identifier of the platform and / or its public key are first obtained from a platform-independent source selected from the group: a printed publication with a mandatory copy, a notarized document, a distributed registry (blockchain), after which the correspondence of the platform identifier extracted from the web page metadata to the identifier obtained from the independent source is verified.

12. The method according to paragraph 1, characterized in that, before publishing, the server sends to the client a draft string signed with the platform key for calculating the fingerprint, and the client locally displays the said string to the user for visual control, calculates F_client and transmits it to the server together with confirmation, while the client fingerprint F_client is stored in the metadata.

13. The method according to paragraph 1, characterized in that the publication web page is returned by the server with the Content-Disposition header containing the canonical name of the file in the format [shortID].html, and when saving the page to the local device, the name of the saved file is compared with the canonical name from the metadata.

14. The method according to paragraph 1, characterized in that when using a qualified electronic signature, the line for signing additionally includes a hash of the author’s biometric sample (Bio_Hash), calculated by the client locally without transmitting biometric data to the server, while Bio_Hash is stored in the metadata.

15. The method according to paragraph 1, characterized in that a service publication is additionally created - a hash block containing the root hash of the Merkle tree constructed from the hashes of publications for the elapsed period, and the hash of the previous hash block, wherein the root hash is additionally recorded in a registry external to the platform, selected from the group: a public blockchain, a notarized document, a printed publication with a mandatory copy.

16. The method according to paragraph 1, characterized in that when using a canonical address (canonicalUrl) containing a full digital fingerprint F in hexadecimal or Base64URL representation, the full fingerprint is extracted from the URL, the control fingerprint F' is calculated from the details extracted from the saved page, and they are compared in full.

17. The method according to paragraph 1, characterized in that a multiple trust anchor is used, including at least two independent sources from the group: a printed publication with a mandatory copy in the national library, a notarized document, an entry in a public distributed registry (blockchain) with a timestamp, each of which contains the domain name and / or IP address of the signing server, the hash of the TLS certificate, the public key and the cryptographic identifier of the platform.

18. The method according to paragraph 1, characterized in that the publication web page is obtained for verification through any available mirror gateway, peer-to-peer content distribution network, or from a locally stored copy, while the authentication is performed without establishing trust in the source that provided the page, solely by recalculating the control fingerprint F' from the details extracted from the page and the URL, and comparing it with the shortID from the URL.

19. The method according to paragraph 1, characterized in that the domain name, IP address and fingerprint of the TLS certificate of the signing server are pre-recorded in a multiple trust anchor, and the client module, when connecting to the signing server, extracts the fingerprint of the presented TLS certificate, calculates its hash and compares it with the reference value obtained from the trust anchor, regardless of the chain of certification authorities.

20. The method according to paragraph 1, characterized in that anonymization of publications is performed upon a verified request of the personal data subject, in which: Before performing anonymization, check for any active court requests, injunctions, or other legal restrictions related to the author's identifier or to a specific publication, and if such restrictions are discovered, anonymization is suspended until they are lifted; a new publication is created with an anonymous author identifier generated in a cryptographically secure way, while the timestamp of the original publication is preserved, and a new digital fingerprint F_new is calculated by replacing the original author identifier with an anonymous one; a notice of the fact of anonymization with cryptographic confirmation of the existence of the original publication is posted at the original address (URL); The link between the original and anonymous author identifiers is stored in the form of a “golden record” containing the original and anonymous identifiers, the original and new hashes, the original and new URLs, the anonymization timestamp, and the legal basis, while the “golden record” is signed with the platform’s cryptographic key, stored in a secure non-public audit table, and disclosed only upon official request of a court or other authorized body.

21. The method according to paragraph 1, characterized in that the proof of inclusion in the Merkle tree (Merkle Proof) is additionally stored in the machine-readable metadata of the web page, containing the serial number of the publication in the tree (leafIndex), an array of intermediate hashes (siblings), a root hash (merkleRoot), a hash block number (blockIndex) and a hash block hash (blockHash), wherein the check for inclusion on the client side is performed without contacting the source server due to the fact that all the necessary data is already contained in the page metadata.