X-Git-Url: http://pere.pagekite.me/gitweb/homepage.git/blobdiff_plain/f858c7734181362b824c31ae0bbabecfdd004a91..4b3704ec7452d7a9e642943dba0cfff18f9d9cc7:/blog/index.rss diff --git a/blog/index.rss b/blog/index.rss index 7ed2e67de6..1b85066ac2 100644 --- a/blog/index.rss +++ b/blog/index.rss @@ -6,6 +6,121 @@ http://people.skolelinux.org/pere/blog/ + + syslog-trusted-timestamp - chain of trusted timestamps for your syslog + http://people.skolelinux.org/pere/blog/syslog_trusted_timestamp___chain_of_trusted_timestamps_for_your_syslog.html + http://people.skolelinux.org/pere/blog/syslog_trusted_timestamp___chain_of_trusted_timestamps_for_your_syslog.html + Fri, 1 Apr 2016 09:50:00 +0200 + <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> + + + Full battery stats collector is now available in Debian http://people.skolelinux.org/pere/blog/Full_battery_stats_collector_is_now_available_in_Debian.html @@ -632,114 +747,5 @@ package show up in unstable.</p> - - Using appstream with isenkram to install hardware related packages in Debian - http://people.skolelinux.org/pere/blog/Using_appstream_with_isenkram_to_install_hardware_related_packages_in_Debian.html - http://people.skolelinux.org/pere/blog/Using_appstream_with_isenkram_to_install_hardware_related_packages_in_Debian.html - Sun, 20 Dec 2015 12:20:00 +0100 - <p>Around three years ago, I created -<a href="http://packages.qa.debian.org/isenkram">the isenkram -system</a> to get a more practical solution in Debian for handing -hardware related packages. A GUI system in the isenkram package will -present a pop-up dialog when some hardware dongle supported by -relevant packages in Debian is inserted into the machine. The same -lookup mechanism to detect packages is available as command line -tools in the isenkram-cli package. In addition to mapping hardware, -it will also map kernel firmware files to packages and make it easy to -install needed firmware packages automatically. The key for this -system to work is a good way to map hardware to packages, in other -words, allow packages to announce what hardware they will work -with.</p> - -<p>I started by providing data files in the isenkram source, and -adding code to download the latest version of these data files at run -time, to ensure every user had the most up to date mapping available. -I also added support for storing the mapping in the Packages file in -the apt repositories, but did not push this approach because while I -was trying to figure out how to best store hardware/package mappings, -<a href="http://www.freedesktop.org/software/appstream/docs/">the -appstream system</a> was announced. I got in touch and suggested to -add the hardware mapping into that data set to be able to use -appstream as a data source, and this was accepted at least for the -Debian version of appstream.</p> - -<p>A few days ago using appstream in Debian for this became possible, -and today I uploaded a new version 0.20 of isenkram adding support for -appstream as a data source for mapping hardware to packages. The only -package so far using appstream to announce its hardware support is my -pymissile package. I got help from Matthias Klumpp with figuring out -how do add the required -<a href="https://appstream.debian.org/html/sid/main/metainfo/pymissile.html">metadata -in pymissile</a>. I added a file debian/pymissile.metainfo.xml with -this content:</p> - -<blockquote><pre> -&lt;?xml version="1.0" encoding="UTF-8"?&gt; -&lt;component&gt; - &lt;id&gt;pymissile&lt;/id&gt; - &lt;metadata_license&gt;MIT&lt;/metadata_license&gt; - &lt;name&gt;pymissile&lt;/name&gt; - &lt;summary&gt;Control original Striker USB Missile Launcher&lt;/summary&gt; - &lt;description&gt; - &lt;p&gt; - Pymissile provides a curses interface to control an original - Marks and Spencer / Striker USB Missile Launcher, as well as a - motion control script to allow a webcamera to control the - launcher. - &lt;/p&gt; - &lt;/description&gt; - &lt;provides&gt; - &lt;modalias&gt;usb:v1130p0202d*&lt;/modalias&gt; - &lt;/provides&gt; -&lt;/component&gt; -</pre></blockquote> - -<p>The key for isenkram is the component/provides/modalias value, -which is a glob style match rule for hardware specific strings -(modalias strings) provided by the Linux kernel. In this case, it -will map to all USB devices with vendor code 1130 and product code -0202.</p> - -<p>Note, it is important that the license of all the metadata files -are compatible to have permissions to aggregate them into archive wide -appstream files. Matthias suggested to use MIT or BSD licenses for -these files. A challenge is figuring out a good id for the data, as -it is supposed to be globally unique and shared across distributions -(in other words, best to coordinate with upstream what to use). But -it can be changed later or, so we went with the package name as -upstream for this project is dormant.</p> - -<p>To get the metadata file installed in the correct location for the -mirror update scripts to pick it up and include its content the -appstream data source, the file must be installed in the binary -package under /usr/share/appdata/. I did this by adding the following -line to debian/pymissile.install:</p> - -<blockquote><pre> -debian/pymissile.metainfo.xml usr/share/appdata -</pre></blockquote> - -<p>With that in place, the command line tool isenkram-lookup will list -all packages useful on the current computer automatically, and the GUI -pop-up handler will propose to install the package not already -installed if a hardware dongle is inserted into the machine in -question.</p> - -<p>Details of the modalias field in appstream is available from the -<a href="https://wiki.debian.org/DEP-11">DEP-11</a> proposal.</p> - -<p>To locate the modalias values of all hardware present in a machine, -try running this command on the command line:</p> - -<blockquote><pre> -cat $(find /sys/devices/|grep modalias) -</pre></blockquote> - -<p>To learn more about the isenkram system, please check out -<a href="http://people.skolelinux.org/pere/blog/tags/isenkram/">my -blog posts tagged isenkram</a>.</p> - - -