X-Git-Url: http://pere.pagekite.me/gitweb/homepage.git/blobdiff_plain/f858c7734181362b824c31ae0bbabecfdd004a91..4b3704ec7452d7a9e642943dba0cfff18f9d9cc7:/blog/index.html diff --git a/blog/index.html b/blog/index.html index 197ab72a13..eb3f0ea06f 100644 --- a/blog/index.html +++ b/blog/index.html @@ -19,6 +19,127 @@ +
+
syslog-trusted-timestamp - chain of trusted timestamps for your syslog
+
1st April 2016
+

Two years ago, I had +a +look at trusted timestamping options available, and among +other things noted a still open +bug in the tsget script +included in openssl that made it harder than necessary to use openssl +as a trusted timestamping client. A few days ago I was told +the Norwegian government office DIFI 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:

+ +

+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
+

+ +

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.

+ +

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.

+ +

+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
+

+ +

Wikipedia have a lot more information about +trusted +Timestamping and +linked +timestamping, and there are several trusted timestamping services +around, both as commercial services and as free and public services. +Among the latter is +the +zeitstempel.dfn.de service mentioned above and +freetsa.org service 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 +RFC 3161 trusted +timestamping protocol standard is even implemented in LibreOffice, +Microsoft Office and Adobe Acrobat, making it possible to verify when +a document was created.

+ +

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 +the +configuration of such feature was described in 2012.

+ +

But I could not find any free implementation of such feature when I +searched, so I decided to try to +build +a prototype named syslog-trusted-timestamp. 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: + +

+syslog-trusted-timestamp /path/to/list-of-log-files
+

+ +

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:

+ +

+syslog-trusted-timestamp --verify /path/to/log-file /path/to/log-with-timestamp
+

+ +

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.

+ +

Please check out +the +prototype for syslog-trusted-timestamp on github 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.

+ +

As usual, if you use Bitcoin and want to show your support of my +activities, please send Bitcoin donations to my address +15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b.

+
+
+ + + Tags: english, sikkerhet. + + +
+
+
+
Full battery stats collector is now available in Debian
23rd March 2016
@@ -699,121 +820,6 @@ package show up in unstable.

-
-
Using appstream with isenkram to install hardware related packages in Debian
-
20th December 2015
-

Around three years ago, I created -the isenkram -system 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.

- -

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, -the -appstream system 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.

- -

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 -metadata -in pymissile. I added a file debian/pymissile.metainfo.xml with -this content:

- -
-<?xml version="1.0" encoding="UTF-8"?>
-<component>
-  <id>pymissile</id>
-  <metadata_license>MIT</metadata_license>
-  <name>pymissile</name>
-  <summary>Control original Striker USB Missile Launcher</summary>
-  <description>
-    <p>
-      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.
-    </p>
-  </description>
-  <provides>
-    <modalias>usb:v1130p0202d*</modalias>
-  </provides>
-</component>
-
- -

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.

- -

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.

- -

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:

- -
-debian/pymissile.metainfo.xml usr/share/appdata
-
- -

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.

- -

Details of the modalias field in appstream is available from the -DEP-11 proposal.

- -

To locate the modalias values of all hardware present in a machine, -try running this command on the command line:

- -
-cat $(find /sys/devices/|grep modalias)
-
- -

To learn more about the isenkram system, please check out -my -blog posts tagged isenkram.

-
-
- - - Tags: debian, english, isenkram. - - -
-
-
-

RSS feed