libreofficeのタイムスタンプが少し問題があったのに気づいてしまった件

あらまし

2024年もよろしくお願いいたします。SRE部のm-ishizukaです。 Timestamp(RFC3161)の実装中にlibreofficeからのリクエストがうまくparseできない自体に陥った。調査をした我々の前に訪れた非情な現実とは？？

timestampとは

近年だと電子帳簿法と向き合っている人には馴染みがあるのでないでしょうか。とあるhash値がとある時間に存在していたことを保証してくれるものです。

たとえばWebアーカイブを取得しても、それが後から改竄されていないことは保証することはできないですが、 timestampを取得していれば、手元のスクリーンショットの画像・PDFなどのtimestampを付与することで、その画像・PDFがtimestampで保証された時刻に存在していた・そのデータ(のハッシュ値)はその時点から改竄されていないことを保証することができます。

freeの実装もあるようです。他にも調べればあるかも？ https://freetsa.org/index_en.php

timestampと聞くと、"2006-01-02T15:04:05Z07:00" を想像しますよね。今回は違います。

突然現れたParse error（一部掻い摘み)

Request parse error, request is not timestamp der format.
MD8CAQEwMTANBglghkgBZQMEAgEFAAQgnni7omOquW5qU+3/EAm3lw8ty8S5TrRrICRvnmi1wCICBCBaWrsBAQE=
2024/01/26 16:57:12 http: panic serving [::1]:59764: asn1: syntax error: invalid boolean
goroutine 19 [running]:
net/http.(*conn).serve.func1()
        /usr/local/Cellar/go/1.21.5/libexec/src/net/http/server.go:1868 +0xb9
panic({0x10033ca20?, 0xc00018c680?})
        /usr/local/Cellar/go/1.21.5/libexec/src/runtime/panic.go:920 +0x270
net/http.HandlerFunc.ServeHTTP(0x10?, {0x100412928?, 0xc00020a000?}, 0xc0001c646c?)
        /usr/local/Cellar/go/1.21.5/libexec/src/net/http/server.go:2136 +0x29
net/http.(*ServeMux).ServeHTTP(0x1000128a5?, {0x100412928, 0xc00020a000}, 0xc0001fe000)
        /usr/local/Cellar/go/1.21.5/libexec/src/net/http/server.go:2514 +0x142
net/http.serverHandler.ServeHTTP({0x100411948?}, {0x100412928?, 0xc00020a000?}, 0x6?)
        /usr/local/Cellar/go/1.21.5/libexec/src/net/http/server.go:2938 +0x8e
net/http.(*conn).serve(0xc0001fa000, {0x1004131e8, 0xc000181320})
        /usr/local/Cellar/go/1.21.5/libexec/src/net/http/server.go:2009 +0x5f4
created by net/http.(*Server).Serve in goroutine 1
        /usr/local/Cellar/go/1.21.5/libexec/src/net/http/server.go:3086 +0x5cb

opensslでパースしてみた。

まずは疑問に思ったのでopensslでparseしてみましょう。

ishizuka@mbp /tmp % echo MD8CAQEwMTANBglghkgBZQMEAgEFAAQgnni7omOquW5qU+3/EAm3lw8ty8S5TrRrICRvnmi1wCICBCBaWrsBAQE= | base64 -d | openssl ts -query -text
Version: 1
Hash Algorithm: sha256
Message data:
    0000 - e7 88 89 9c 64 01 e5 83-cf 50 6b 64 f3 ca 31 8d   ....d....Pkd..1.
    0010 - bc 71 c8 80 17 1a 48 1f-18 89 d3 c5 d1 af 1f 0d   .q....H.........
Policy OID: unspecified
Nonce: 0x56F8AA90E293EB1B
Certificate required: no
Extensions:

parseできるぞ・・・？

ishizuka@mbp /tmp % echo MD8CAQEwMTANBglghkgBZQMEAgEFAAQgnni7omOquW5qU+3/EAm3lw8ty8S5TrRrICRvnmi1wCICBCBaWrsBAQE= | base64 -d | openssl asn1parse -inform der
    0:d=0  hl=2 l=  63 cons: SEQUENCE
    2:d=1  hl=2 l=   1 prim: INTEGER           :01
    5:d=1  hl=2 l=  49 cons: SEQUENCE
    7:d=2  hl=2 l=  13 cons: SEQUENCE
    9:d=3  hl=2 l=   9 prim: OBJECT            :sha256
   20:d=3  hl=2 l=   0 prim: NULL
   22:d=2  hl=2 l=  32 prim: OCTET STRING      [HEX DUMP]:9E78BBA263AAB96E6A53EDFF1009B7970F2DCBC4B94EB46B20246F9E68B5C022
   56:d=1  hl=2 l=   4 prim: INTEGER           :205A5ABB
   62:d=1  hl=2 l=   1 prim: BOOLEAN           :1

しょうがないのでASN.1レベルで処理できる証明書と比較

Adobe Acrobat Readerからのリクエストの場合

ishizuka@mbp /tmp % echo MEMCAQEwMTANBglghkgBZQMEAgEFAAQgtwhCmGn9cA41oN7ld0zRDn6s+M7nsaVojFCjPtTZVBQCCAwpp2w4gIFyAQH/ | base64 -d | openssl asn1parse -inform der
    0:d=0  hl=2 l=  67 cons: SEQUENCE
    2:d=1  hl=2 l=   1 prim: INTEGER           :01
    5:d=1  hl=2 l=  49 cons: SEQUENCE
    7:d=2  hl=2 l=  13 cons: SEQUENCE
    9:d=3  hl=2 l=   9 prim: OBJECT            :sha256
   20:d=3  hl=2 l=   0 prim: NULL
   22:d=2  hl=2 l=  32 prim: OCTET STRING      [HEX DUMP]:B708429869FD700E35A0DEE5774CD10E7EACF8CEE7B1A5688C50A33ED4D95414
   56:d=1  hl=2 l=   8 prim: INTEGER           :0C29A76C38808172
   66:d=1  hl=2 l=   1 prim: BOOLEAN           :255

おやおやおや？？？ここで違いのわかる漢であれば分かるらしい。

※私は30分ググりました。

ご安心下さい。すぐに気づける人はX.690 DER encodingを脳内でデコードできる人です。違いのわかる漢に早くなりたいです。

答え。

   62:d=1  hl=2 l=   1 prim: BOOLEAN           :1

ASN1 / DER encodedにおけるBOOLEAN trueは、0xffのみで、0x01は未定義。

＃エラーが正しい。というのがgolang ＃00じゃなければTrueにしちゃったのが昔の一部の実装

過去にも似たように問題があったとかなんとか

WIDE project のCA https://www.wide.ad.jp/About/report/pdf2005/part19.pdf
他の開発者のMR(golang) https://github.com/golang/go/issues/11091

booleanで0x01が未定義って結構ハマりますよね。解ります。

どこに問題があるか調べよう。

今回は運良くコードにRFC3161のフレーズがコメントがあったので、サクッと当該コードが見つかる。

ishizuka@mbp ~/github/libreoffice-core % grep -ri rfc3161 .
./svl/source/crypto/cryptosign.cxx

  1039          unsigned char cOne = 1;
  1058          src.certReq.type = siUnsignedInteger;
  1059          src.certReq.data = &cOne;
  1060          src.certReq.len = sizeof(cOne);

ここがいけなさそう。多分。

          unsigned char cBoolTrue = 255;
          src.certReq.data = &cBoolTrue;
          src.certReq.len = sizeof(cBoolTrue);

なら多分動くんじゃないかな？

答えもわかったので、とりあえず報告。

https://bugs.documentfoundation.org/show_bug.cgi?id=159381

2024-01-26 09:21:51 UTC 報告
2024-01-27 16:44:47 UTC 24.8.0(2024/08ごろリリースバージョン？)に取り込まれ
2024-01-27 21:48:16 UTC 24.2.1(2024/02ごろリリースバージョン？)に取り込まれ

大勝利!!

実際に取り込まれたコード

https://git.libreoffice.org/core/+/42e06fb686d4c02fc6efaf0a792319147e3d62bf%5E%21

        unsigned char cTRUE = 0xff; // under DER rules true is 0xff, false is 0x00
        src.certReq.data = &cTRUE;
        src.certReq.len = sizeof(cTRUE);

おしい。わたしの詰めの甘さが露呈してしまいました

まとめ。

古から散見していたDERエンコードのTRUEは0xFF問題を一つ駆逐した
timestampの利用者が少しでも増えてくれれば