Skip to content

A system to sign and verify the authenticity and originality of documents using RSA cryptography

License

Notifications You must be signed in to change notification settings

nic-obert/document-signing-and-verification-system

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

5 Commits
 
 
 
 
 
 

Repository files navigation

Document Signing and Verification System

This project aims to create a protocol for signing documents using RSA cryptography. This barebone Python demo shows the technical signing and verification parts of the protocol.

Objectives

  • Sign and verify a document using RSA cryptography
  • Include metadata in the signature to provide untampered information about the document (author, date, license, etc.)

The signing and verification system

Premises

A centralized digital ID provider is used to create digital IDs. In a real-world scenario, this would be a government agency or a trusted third party.
It is crucial that the ID provider is trusted by all parties and that it is not compromised. If the ID provider is compromised, the whole system is compromised.

The ID provider creates a digital ID for each user and generates a public and private key pair for each ID. The public key, along with some data about the author, is made publicly available through an API, while the private key is kept secret.
Ideally, the private key would be encrypted with a two-way encryption algorithm that uses a secret as the encryption key (the account password, for instance).

The digital ID accounts must be protected by strong security measures. Multi-factor authentication is mandatory, and the ID provider should provide a way to recover the account in case of loss of one of the authentication factors.

The ID provider also provides a service to sign documents. The signing is done exclusively on the provider side in order not to expose the private key to the user, who may accidentally leak it or use it to sign documents with false metadata (specifically, we are talking about the timestamp field that may be used to claim a past or future timestamp).

The system implies that only documents signed through the official ID provider can be verified and thus trusted. Documents published without a signature or signed by a third party cannot be trusted.
The private key is kept secret even from the user so that the user cannot sign documents with false metadata.

The hashing algorithm used to sign the documents must be resistant to collisions to prevent forgery, and relatively slow to compute to prevent brute-force attacks.
The RSA keys must also be long enough to prevent brute-force attacks.

This system requires no additional infrastructure, as it can be implemented on top of an existing ID provider service without the need for additional servers or databases.

Signing

The signing service allows the user to upload a document (any kind of file: video, image, text, blob, etc.) and fill in some metadata about the document.
The metadata includes the following mandatory fields, which are automatically filled in by the service provider:

  • author UUID: the UUID of the author of the document. This is used to retrieve the public key of the author and other information from the ID provider. The UUID is the only true identifier, as the author may decide to alter the author name, organization, etc., but the UUID will always be the same.
  • timestamp: the timestamp of when the document was signed. This is used to prevent the user from signing a document with a timestamp in the past. The timestamp is automatically generated by the service provider to prevent the user from tampering with it. Also, if another user tries to later sign the same document and claims its authorship, the timestamp will be different, thus allowing the identification of the original author by comparing timestamps. For locale-independent and consistent timestamp generation, the service provider should use UTC.

Other optional fields can be included in the metadata (the list is not exhaustive):

  • author name: the name of the author or the name of the program that generated the document. An author may decide to alter this field, but their identity will be revealed by the author UUID anyway.
  • organization: the organization the author or the content generation tool belongs to.
  • license: the license the document is published under.
  • location: the location where the document was signed or created. This may be useful to store the location of a photo or video, for instance.
  • title: the title of the document. This may be useful to store the title of a photo, video, or book, for instance.
  • description: a description of the document.
  • edited from: a link to the resource the document was edited from. This may be useful to store the link to an original photo.

The document is first hashed locally to save bandwidth and it's then sent to the provider's server. The signing service then concatenates the document hash and the metadata into a blob.
The resulting blob is then hashed again and signed using the author's private key.
The signature and metadata are then either included in a local copy of the document if the file format allows it, or returned in a separate file.

The author can then publish the document with its signature and metadata.
Ideally, the file format of the document would allow the signature and metadata to be included directly in the document so that the document can be passed around and verified without the need for a separate file. Alternatively, the signature and metadata can be published in a separate file.

Verification

The verification service allows anyone to verify the authenticity of a document, given its signature and metadata. A public API is provided to expose public keys

First, the supposed author's public key is retrieved from the ID provider using the author UUID found in the metadata.
The document is hashed, concatenated with the metadata, and hashed again. The resulting hash is then verified against the signature using the author's public key.

If the verification is successful, the document is authentic and the metadata can be trusted.
If the verification fails, there are various possibilities:

  • the document content has been tampered with (edited, corrupted, etc.)
  • the metadata has been tampered with (different author UUID, different timestamp, etc.)
  • the signature has been tampered with (different signature)

Use cases

Authors can use this system to sign their documents and prove their authorship.
An author can be any person or organization, or even a program that generates content like generative AI models.

Content creators can use this system to prevent their intellectual property from being stolen. The timestamp will prove that the content was created by the author before anyone else.

Public generative AI providers can sign their generated content to comply with legal regulations (see the new EU AI Act of late 2023).

License

This project is licensed under the MIT License - see the LICENSE file for details.

About

A system to sign and verify the authenticity and originality of documents using RSA cryptography

Topics

Resources

License

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published

Languages