Seal Document with Blockchain

DE | EN

Upload a file with the file dialog or by dragging and dropping a file onto the dashed region.

Reset
:

Reset

With the following commands you can calculate the hash value and sign a file for verification using OpenSSL.

Calculate hash value
cat file.dat | openssl dgst -sha256
Sign file and calculate hash value
cat file.dat | \
    gpg --detach-sig -u your.email@provider.com | \ 
    openssl dgst -sha256

Use this form to validate the root node of a Merkle tree with given hash value and audit proof.





Reset
About hash value 006748c21efaf8fe67b833d82cba7955619c3c3b06e11ed6562fbf6a1cb06f2c
  • at the hash value was created on this website
  • at the hash value was stored in Ethereum -
    How to independently check the date in Ethereum:
    1. Create the hash value (006748c21efaf8fe67b833d82cba7955619c3c3b06e11ed6562fbf6a1cb06f2c) of the file - for example here
    2. Use the hash value and the following hashes to calculate the Merkle root node as described in RFC 6962:
      -85b344b468226a6cc6e6c6ebccb8218abe6481909dcc27e6cb2e73d93cb69239, -6f03717d704aca10d830f2246d21366dedd5d158f3bd3a16c45fbcbfec71fcab
    3. Check if this value (dca41f7b34dc82038e1867e87409bcae5c09b6e8ef3dfc0663a351b6fcb300a2) is stored in the Ethereum blockchain at the following address: a87ddd5578841bf21965ac3145a5163b1cff6a2c2328d388749b44fd8b8ad5dd (show on Etherscan.io)
    4. the timestamp stored in the Ethereum blockchain at the specified address is the independently verified time for the first upload of the file

     

  • at the hash value was digitally sigend with a trusted timestamp - | view stamp
    How to verify the digital timestamp from freetsa.org:
    1. download file.tsr, cacert.pem, and tsa.crt
    2. run the following command in the folder with the downloaded files:
      openssl ts -verify -data <(echo -n "006748c21efaf8fe67b833d82cba7955619c3c3b06e11ed6562fbf6a1cb06f2c") \
          -in file.tsr -CAfile cacert.pem -untrusted tsa.crt

Click on a topic to show further information.

The blockchain are cryptographically linked and decentrally stored datasets. Each dataset contains a fingerprint (hash value) of the previous dataset, a time stamp and further transaction data. Because later sets build on previous sets and confirm them as correct, it is impossible to change or delete those earlier sets without changing all the data that builds on them. However, such a change is not possible due to the distributed storage of the data and would be recognized immediately.

Sealing documents uses this guaranteed data integrity property of the blockchain.

The Public Charity to Foster Personal Use of Data has set itself the goal of promoting the self-determined use of personal data by private individuals. Blockchain technology provides nowadays a simple and secure way to verify data integrity for private data use, and therefore the Public Charity offers this service. By combining transactions - current grouping all transactions of a day - the necessary transaction costs can be kept low and are covered by the budget of the Public Charity.

On Github the source code for this website is freely available under the MIT license: https://github.com/OwnYourData/app-seal

The document sealing service uses a freely accessible API in the background, which can also be used by other services. By means of an HTTP POST request the hash value can be written to the blockchain, or - if the hash value has already been used - the address in the blockchain is returned. Since all hash values of a day are combined in a Merkle tree, the audit proof is made available in addition to the address in the blockchain (as described in RFC 6962).

This API is described using Swagger here: https://blockchain.ownyourdata.eu/doc
On Github, the source code for the API service is freely available under the MIT license:

Use the following shell command to save a hash value via API in the blockchain:

$ curl -X POST "https://blockchain.ownyourdata.eu/api/doc?hash=006748c21efaf8fe67b833d82cba7955619c3c3b06e11ed6562fbf6a1cb06f2c"

The first call returns the following JSON structure as the return value:

{
  "status": "new",
  "address": "",
  "root-node": "",
  "audit-proof": [],
  "dlt-timestamp": "",
  "oyd-timestamp": "2018-09-01T22:39:16Z"
}

Once all hash values of a day have actually been written to the blockchain, the return value contains the following further information:

{
  "status": "exist",
  "address": "0xcf4a0cf4b9ea6d10c0407680fe1f73df1a59c362db29a1863e14d85fcdb69c9c",
  "root-node": "10611bc55c740b46517ce15ad82b79350468affc4660379771475eaa494ec3fd",
  "audit-proof": "+661eec906b6a88b3bf751d7f5c62b84de03fadaed78e9398efebf408b2a3236c,
                  -0cdf07531250367444ae8a3bfcbb0b928e1313ece65f2a45abcc2226e278d6cd,
                  -5cbe1017c15d83ce8f4c02b4c1d8d2fa0c51bbe281363d98ef7dc33ffe26a072",
  "dlt-timestamp": "2018-09-02T06:00:17Z",
  "oyd-timestamp": "2018-09-01T22:39:16Z"
}

Note: the signs (+, -) in the audit-proof field indicate whether the respective hash value should be considered as the left (+) or right (-) node in the root node calculation check - see also RFC 6962. SHA256 is generally used as the hash function.

A Merkle tree is a binary tree, i.e., each node has at most 2 child nodes. The leaves are hash values and each 2 adjacent nodes form a higher-level node. The hash value of a sheet, together with the audit proof (as defined in RFC 6962) unambigously identify the root node of a merkle tree. When using the audit proof, it is important to specify whether the hash value is to be used as left or right node.

This service identifies values in the audit proof by + (left node) and - (right node) as first character. Together with the hash value, the root node can be calculated this way. The procedure of the Merkle tree is used to arrange all received hash values of a day in this binary tree and then store only the root node itself in the blockchain.

Trusted timestamping is the process of securely keeping track of the date and status of a document. Security here means that no one - not even the owner of the document - is able to change the timestamp once it has been recorded. The timestamp offered here follows the standard RFC 3161 and can be applied to time-sensitive transactions through independently verified and auditable date and UTC (Coordinated Universal Time) sources.

Adding a trusted timestamp to a document provides a digital seal of data integrity and a trusted date and time of when the transaction took place. Recipients of documents and code with a trusted timestamp can verify when the document was digitally or electronically signed, as well as verify that the document or code was not altered after the date the timestamp vouches for.