X-Git-Url: https://pere.pagekite.me/gitweb/homepage.git/blobdiff_plain/3e8c4bf87aeaa0c186308fd80e471e22eb8dc523..4b3704ec7452d7a9e642943dba0cfff18f9d9cc7:/blog/tags/english/index.html?ds=sidebyside diff --git a/blog/tags/english/index.html b/blog/tags/english/index.html index 24437079ea..ca721e9d90 100644 --- a/blog/tags/english/index.html +++ b/blog/tags/english/index.html @@ -20,6 +20,201 @@

Entries tagged "english".

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

Since this morning, the battery-stats package in Debian include an +extended collector that will collect the complete battery history for +later processing and graphing. The original collector store the +battery level as percentage of last full level, while the new +collector also record battery vendor, model, serial number, design +full level, last full level and current battery level. This make it +possible to predict the lifetime of the battery as well as visualise +the energy flow when the battery is charging or discharging.

+ +

The new tools are available in /usr/share/battery-stats/ +in the version 0.5.1 package in unstable. Get the new battery level graph +and lifetime prediction by running: + +

+/usr/share/battery-stats/battery-stats-graph /var/log/battery-stats.csv
+

+ +

Or select the 'Battery Level Graph' from your application menu.

+ +

The flow in/out of the battery can be seen by running (no menu +entry yet):

+ +

+/usr/share/battery-stats/battery-stats-graph-flow
+

+ +

I'm not quite happy with the way the data is visualised, at least +when there are few data points. The graphs look a bit better with a +few years of data.

+ +

A while back one important feature I use in the battery stats +collector broke in Debian. The scripts in +/usr/lib/pm-utils/power.d/ were no longer executed. I +suspect it happened when Jessie started using systemd, but I do not +know. The issue is reported as +bug #818649 against +pm-utils. I managed to work around it by adding an udev rule to call +the collector script every time the power connector is connected and +disconnected. With this fix in place it was finally time to make a +new release of the package, and get it into Debian.

+ +

If you are interested in how your laptop battery is doing, please +check out the +battery-stats +in Debian unstable, or rebuild it on Jessie to get it working on +Debian stable. :) The upstream source is available from +github. +As always, patches are very welcome.

+ +
+
+ + + Tags: debian, english. + + +
+
+
+
UsingQR - "Electronic" paper invoices using JSON and QR codes @@ -46,7 +241,7 @@ a QR code with the key information of the invoice in JSON format. This is the typical content of a QR code following the UsingQR specification (based on a real world example, some numbers replaced to get a more bogus entry). I've reformatted the JSON to make it easier -to read. Normally this is all on one long line: +to read. Normally this is all on one long line:

 {
@@ -92,7 +287,7 @@ risk, but if this happen there is some legal defense in the fact that
 the people behind the format claimed it was safe to do so.  At least
 with patents, there is always
 a
-chance of getting sued...
+chance of getting sued...

I also asked if they planned to maintain the format in an independent standard organization to give others more confidence that @@ -104,6 +299,27 @@ they conclude that using an open standard organisation like IETF is the correct place to maintain such specification.

+

Update 2016-03-20: Via Twitter I became aware of +some comments +about this blog post that had several useful links and references to +similar systems. In the Czech republic, the Czech Banking Association +standard #26, with short name SPAYD, uses QR codes with payment +information. More information is available from the Wikipedia page on +Short +Payment Descriptor. And in Germany, there is a system named +BezahlCode, +(specification +v1.8 2013-12-05 available as PDF), which uses QR codes with +URL-like formatting using "bank:" as the URI schema/protocol to +provide the payment information. There is also the +ZUGFeRD +file format that perhaps could be transfered using QR codes, but I am +not sure if it is done already. Last, in Bolivia there are reports +that tax information since november 2014 need to be printed in QR +format on invoices. I have not been able to track down a +specification for this format, because of my limited language skill +sets.

+
@@ -24880,7 +25096,9 @@ be the only one fitting our needs. :/

  • February (2)
  • -
  • March (2)
  • +
  • March (3)
  • + +
  • April (1)
  • @@ -25119,7 +25337,7 @@ be the only one fitting our needs. :/

  • chrpath (2)
  • -
  • debian (121)
  • +
  • debian (122)
  • debian edu (154)
  • @@ -25131,7 +25349,7 @@ be the only one fitting our needs. :/

  • drivstoffpriser (4)
  • -
  • english (304)
  • +
  • english (306)
  • fiksgatami (23)
  • @@ -25193,7 +25411,7 @@ be the only one fitting our needs. :/

  • scraperwiki (2)
  • -
  • sikkerhet (45)
  • +
  • sikkerhet (46)
  • sitesummary (4)