Idea for storing trusted timestamps in Noark 5

[Thomas Sødring]

On 09/18/2018 04:14 PM, Petter Reinholdtsen wrote:
> I would like to pick up on this idea to store information in the archive
> that can be used to verify that an electronic document have not changed
> since it was archived.
I think that's a good idea! We have a ongoing blockchain project at the
moment so it would be interesting to show TTP as an alternative to
blockchain and perhaps write an article about it.
>
> There are several ways to verify this, and here I will focus on RFC
> 3161, the Trusted Timestamping protocol.  The protocol is used by many,
> like Adobe to stamp PDFs and Microsoft to stamp binaries.  I believe it
> would be a huge step forward if Nikita would use it to stamp documents.
>
> The stamp is a binary blob consisting based on a cryptographic hash H of
> the document, the current time T and the private key K of the
> timestamping servie with public key P.  The stamp is a statement
> claiming that 'the timestamping service saw the hash H at time T', and
> as long as the private key K is kept secret, anyone with the public key
> P can be sure that only those with proper access to key K have made such
> claim.
I have just implemented an open source teaching took for PKI in Java
(https://gitlab.com/OsloMet-ABI/chestnut) so I have a lot of PKI-stuff
fresh in memory. Now is a good time to take a look at this.

I see the process of verifying a document along the lines of an advanced
offentlig journal (public journal). We are slowly getting OData support
into nikita and think that we might be able to do something here.
Perhaps nikita could publish a list of all documents along with the
timestamp. The contents of the document need not be published

So we have:
- systemId of a documentObject
- a document hash (sha-256)
- timestamp

This could result in something like the following json payload

{
 "systemID" : "fb77f691-6f51-4421-8be9-829d18220c36",   
 "documentChecksum" :
"2D711642B726B04401627CA9FBAC32F5C8530FB1903CC4DB02258717921A4881",
 "timestamp": 132643950
}

This would result in a signature that would resemble something like the
following (base64-encoded):

cVlFQkD6mcQdEOwMCYsBlimTaaxAoFeNp4rjcqjKGF2
nCldrL1TZXbCNxOQ2fsZ3ZyHfSr1ooBkJSzcGyjKGexu
S3Bf/AbpNSYClrspgp7dv8Z9koH3LKgxZM4FOXu6ctnI
RvTqhmhta8iJcPG/PKME+oLKOXYWSddYYsL0u1C9fR
yhEHilExw+W5aCHwz31L/UXORK3u5frRsTaLfW669Q
S/NEdBLvs1xISoFgb+SS6vwsnRGg9F+v8TXDa7QMNN
wfQaiIiYd+95GRuLk0dYt26CqEYxQW9JNNa+ydu2lIS8
3LEi955v7+qB0DYQhewmgLChAXKCBdYXdjlKaqm1w==

(The signature was formated for brevity)

This is what you are proposing Petter, if I understand you correctly.
The above signature can be verified using a public key.

>
> If we store the binary stamp blob alongside public key K (and preferably
> its certificate signature chain), we have everything we need to confirm
> that a binary with hash H have not been chanced since the stamp was
> created.
>
> So, given a binary blob around 2.5k in size, and a certificate possibly
> 6k in size, how can we best store this in the archive to have what is
> needed to state with confidence that the documents are unchanged?

The thing we are missing perhaps is the trusted thrid party. The
software that does the signing for us. We could create a simple
proof-of-concept on one of the other machines we have. A simple signing
service that takes the above JSON payload and produces a signature. This
would be a SIGN-functionality

This could also have a VERIFY-functionality that takes a signature and
verifies that the signature is in fact correct. But that's all that it
does.

Perhaps the problem here is how to deal with a situation where the
private key has been exposed. Not having documents, but just hashes
means it's relatively simple to resign all the data.

>
> Note, it is perfectly possible to get several stamps for one document.
> Every extra stamp increases the confidence in the documents validity, as
> it is more than twice as hard to break into two timestamping vendors and
> steal their private key than to break into only one of them. :)
>
> Kent suggested to store the binary blob in a noark 5 metadata field.
> Where could it go?
I'm not sure if this is something we would want in a Noark system. In
many ways this could be a external service that we trust independent of
the record-keeping core. At some stage when documents start arriving
into an archive, we could regenerate the hash for the documents and
verify the documents. Thatwould be a nice thing for society to have!

>
> I suggested to store it as a new document with a name derived from the
> document being signed.  I know how to do this, but am not convinced it
> is the best way to do it.
>
> Anyone got any other suggestions?  A goal must be for the stamps to make
> it into the national archive when a Noark 5 archive is placed in their
> depot, so we need to follow the requirements provided by the national
> archive.
This is in essence the same problem we're facing with the block-chain
project, how do deal with the signatures. Assuming the sign/verify nodes
are present in the future is not possible! So the nodes themselves would
also become subject to preservation, but as the signatures do not expose
data, they could perhaps be replicated in another countries national
archive!
>
> In addition to using openssl, one can use both a java library Bounty
> castle and the Python library rfc3161ng.  This would allow us to
> implement the signing on both the client and server end, if we figure
> out how to best do it. :)
>
It's just a matter of starting with a proof-of-concept! If we can agree
on an example JSON Payload then we could just implent it and discuss it.
I do think this work is publishable! I think there are some conferences
that would be happy to publish something that isn't just "blockchain"


 - Tom