Petter Reinholdtsen

For litt mer enn et år siden laget jeg litt statistikk for 2013 og 2014 basert på Offentlig elektronisk postjournal (OEP). Tallene finnes i tre bloggposter, en over hvem som er mest hemmelighetsfulle, en annen med hvor mye som mangler og en om hvor stor andel dokumenter som journalføres mer enn 180 dager etter dokumentdato. Jeg synes det er interessant å se hvordan det utvikler seg over tid, så her tallene for 2015 og 2014. 2014-tallene bør være de samme som sist, men kan ha litt avvik på grunn av endringer/korreksjoner gjort i OEP. Denne gangen har jeg samlet alle tallene i samme bloggpost.

Først kommer statistikken over antall dokumenter som er registrert unntatt offentligheten i OEP. Merk at klassifiseringen i OEP er foreløpig, slik at en kan få innsyn i dokumenter merket unntatt offentlighet når en spør, etter nærmere vurdering. Det er dermed ikke gitt at prosentsatsen representerer hvor mange dokumenter som ville blitt holdt tilbake på forespørsel.

Interessant å se hvordan Utenriksdepartementet tilsynelatende er blitt ekstremt mer hemmelighetsfull på tre år. I 2015 var 99,8% av 71409 dokumenter merket som unntatt offentlighet, mens i 2014 var det 44,3% av 65121 og og i 2013 var det bare 12,1% av 67828. Lurer på hva som har skjedd.

Dernest kommer statistikken over hvor mange saksnummer og dokumenter som ikke finnes i OEP (dvs. hull i saksnummer- og dokumentnummerserien). Se tidligere omtalte bloggpost for å forstå hvordan slike hull kan oppstå uten at det er noe galt eller mistenkelig med det.

Til sist er statistikken over hvor stor andel av utgående, inngående, og andre dokumenter som blir journalført mer enn 180 dager etter dokumentets dato, dvs. hvor stor andel som blir journalført ekstremt sent for utgående og interne dokumenter, mens det for innkommende like gjerne kan være at det tok lang tid før de ble mottatt.

Jeg lurer virkelig på hvordan så mange i det offentlige klarer å ikke journalføre utgående dokumenter med en gang de gjøres ferdig. Er det manglende opplæring, vanskelige systemer, vond vilje eller noe helt annet som er årsaken? Det hadde vært interessant å finne ut om det var noen fellestrekk for dokumenter som ikke blir journalført før det er gått et halvt år.

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.