+ <item>
+ <title>syslog-trusted-timestamp - chain of trusted timestamps for your syslog</title>
+ <link>http://people.skolelinux.org/pere/blog/syslog_trusted_timestamp___chain_of_trusted_timestamps_for_your_syslog.html</link>
+ <guid isPermaLink="true">http://people.skolelinux.org/pere/blog/syslog_trusted_timestamp___chain_of_trusted_timestamps_for_your_syslog.html</guid>
+ <pubDate>Fri, 1 Apr 2016 09:50:00 +0200</pubDate>
+ <description><p>Two years ago, I had
+<a href="http://people.skolelinux.org/pere/blog/Public_Trusted_Timestamping_services_for_everyone.html">a
+look at trusted timestamping options available</a>, and among
+other things noted a still open
+<a href="https://bugs.debian.org/742553">bug in the tsget script</a>
+included in openssl that made it harder than necessary to use openssl
+as a trusted timestamping client. A few days ago I was told
+<a href="https::/www.difi.no/">the Norwegian government office DIFI</a> is
+close to releasing their own trusted timestamp service, and in the
+process I was happy to learn about a replacement for the tsget script
+using only curl:</p>
+
+<p><pre>
+openssl ts -query -data "/etc/shells" -cert -sha256 -no_nonce \
+ | curl -s -H "Content-Type: application/timestamp-query" \
+ --data-binary "@-" http://zeitstempel.dfn.de > etc-shells.tsr
+openssl ts -reply -text -in etc-shells.tsr
+</pre></p>
+
+<p>This produces a binary timestamp file (etc-shells.tsr) which can be
+used to verify that the content of the file /etc/shell with the
+calculated sha256 hash existed at the point in time when the request
+was made. The last command extract the content of the etc-shells.tsr
+in human readable form. The idea behind such timestamp is to be able
+to prove using cryptography that the content of a file have not
+changed since the file was stamped.</p>
+
+<p>To verify that the file on disk match the public key signature in
+the timestamp file, run the following commands. It make sure you have
+the required certificate for the trusted timestamp service available
+and use it to compare the file content with the timestamp. In
+production, one should of course use a better method to verify the
+service certificate.</p>
+
+<p><pre>
+wget -O ca-cert.txt https://pki.pca.dfn.de/global-services-ca/pub/cacert/chain.txt
+openssl ts -verify -data /etc/shells -in etc-shells.tsr -CAfile ca-cert.txt -text
+</pre></p>
+
+<p>Wikipedia have a lot more information about
+<a href="https://en.wikipedia.org/wiki/Trusted_timestamping">trusted
+Timestamping</a> and
+<a href="https://en.wikipedia.org/wiki/Linked_timestamping">linked
+timestamping</a>, and there are several trusted timestamping services
+around, both as commercial services and as free and public services.
+Among the latter is
+<a href="https://www.pki.dfn.de/zeitstempeldienst/">the
+zeitstempel.dfn.de service</a> mentioned above and
+<a href="https://freetsa.org/">freetsa.org service</a> linked to from the
+wikipedia web site. I believe the DIFI service should show up on
+https://tsa.difi.no, but it is not available to the public at the
+moment. I hope this will change when it is into production. The
+<a href="https://tools.ietf.org/html/rfc3161">RFC 3161</a> trusted
+timestamping protocol standard is even implemented in LibreOffice,
+Microsoft Office and Adobe Acrobat, making it possible to verify when
+a document was created.</p>
+
+<p>I would find it useful to be able to use such trusted timestamp
+service to make it possible to verify that my stored syslog files have
+not been tampered with. This is not a new idea. I found one example
+implemented on the Endian network appliances where
+<a href="http://help.endian.com/entries/21518508-Enabling-Timestamping-on-log-files-">the
+configuration of such feature was described in 2012</a>.</p>
+
+<p>But I could not find any free implementation of such feature when I
+searched, so I decided to try to
+<a href="https://github.com/petterreinholdtsen/syslog-trusted-timestamp">build
+a prototype named syslog-trusted-timestamp</a>. My idea is to
+generate a timestamp of the old log files after they are rotated, and
+store the timestamp in the new log file just after rotation. This
+will form a chain that would make it possible to see if any old log
+files are tampered with. But syslog is bad at handling kilobytes of
+binary data, so I decided to base64 encode the timestamp and add an ID
+and line sequence numbers to the base64 data to make it possible to
+reassemble the timestamp file again. To use it, simply run it like
+this:
+
+<p><pre>
+syslog-trusted-timestamp /path/to/list-of-log-files
+</pre></p>
+
+<p>This will send a timestamp from one or more timestamp services (not
+yet decided nor implemented) for each listed file to the syslog using
+logger(1). To verify the timestamp, the same program is used with the
+--verify option:</p>
+
+<p><pre>
+syslog-trusted-timestamp --verify /path/to/log-file /path/to/log-with-timestamp
+</pre></p>
+
+<p>The verification step is not yet well designed. The current
+implementation depend on the file path being unique and unchanging,
+and this is not a solid assumption. It also uses process number as
+timestamp ID, and this is bound to create ID collisions. I hope to
+have time to come up with a better way to handle timestamp IDs and
+verification later.</p>
+
+<p>Please check out
+<a href="https://github.com/petterreinholdtsen/syslog-trusted-timestamp">the
+prototype for syslog-trusted-timestamp on github</a> and send
+suggestions and improvement, or let me know if there already exist a
+similar system for timestamping logs already to allow me to join
+forces with others with the same interest.</p>
+
+<p>As usual, if you use Bitcoin and want to show your support of my
+activities, please send Bitcoin donations to my address
+<b><a href="bitcoin:15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b">15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b</a></b>.</p>
+</description>
+ </item>
+
projects / homepage.git / commitdiff