checksum・signature・provenanceは別の保証をする
ソフトウェア配布の検証では、checksum、digital signature、provenanceが同じ「改竄検知」の手段として並べられがちだが、実際には答えている問いが異なる。
aquaはupstream releaseを正規化するパッケージマネージャーと捉えられる や Nixのstore pathは通常content-addressedではない を比較すると、この差が特に重要になる。
checksum: 期待したbytesか
cryptographic hashで確認できるのは、基本的には「取得したbytesが、期待していたdigestを持つbytesと同一か」である。これは転送中の破損検出や、別経路で安全に得たdigestとの照合には有効である。
しかしartifactとchecksum fileを同じ侵害されたrelease pageから同時に取得するだけなら、攻撃者が両方を差し替えることもできる。したがってchecksum verificationだけでは「このdigestを誰が正しいと認めたか」というauthenticityの起点は生まれない。
aquaはregistryでchecksum assetを指定できるが、公式ドキュメントではchecksum downloadはpackage設定によるとしている。aquaがCosignやSLSA Provenanceも別フィールドとして扱うこと自体、checksumと署名・provenanceが異なる保証であることを示している。
signature: 誰の鍵・identityがこのartifactを認めたか
digital signatureは、信頼しているpublic keyやidentity policyと組み合わせることで、「対応するprivate keyを持つ主体がこのmessage/artifactに署名した」というauthenticityを検証できる。
ただし「署名されている」だけでは十分ではない。誰の署名なら、そのpackageについて受け入れるのかというpolicyが必要になる。Sigstoreのthreat modelも、signature verificationはsigner identityとの対応を示すが、そのidentityを信用すべきか、artifactが安全なsoftwareかまでは保証しないと明示している。
このため署名検証には、artifact名と許可されたsigner identityの対応、identity provider、key rotation/revocationなどのtrust policyが伴う。
provenance: どこから、どう作られたか
SLSAでいうprovenanceは、artifactがどこで、いつ、どのように作られたかを追跡可能にするverifiable informationである。Build Provenanceでは、builder、build process、source/inputなどを記録し、consumerが「期待したbuild processから生成されたartifactか」を検証できるようにする。
SLSA 1.2のBuild Trackでは、L1はprovenanceが存在する段階、L2はhosted build platform自身がprovenanceを生成・署名する段階、L3はbuild platform自体をhardenする段階と整理されている。つまりprovenanceというJSONが添付されているだけで強い保証になるわけではなく、誰がどの境界でprovenanceを生成したかまでがsecurity modelに含まれる。
三つを分離すると見えること
- checksum:
artifact A == expected bytes? - signature:
trusted signer/identityがartifact Aを認証したか? - provenance:
artifact Aは期待したsource・inputs・builder・processから生成されたか?
さらにこの三つでも「最新版か」は答えられない。過去に正当に署名された脆弱なversionを攻撃者が再提示するrollback/freeze attackは成立し得る。この問題は 署名検証だけではrollback・freeze attackを防げない の領域になる。
content addressingも同様である。Nixのstore pathは通常content-addressedではない のcontent-addressed objectは、取得したcontentとaddressの自己整合性を検証できるが、「そのcontentを誰が、正しいsourceから、正しいbuilderで作ったか」はprovenanceではない。したがって content addressingはprovenanceではない としてさらに分離できる。
パッケージマネージャーのsecurityを比較するときは、「hashがある」「署名がある」「SLSA対応」と機能名だけを数えるのではなく、どの問いに答える検証なのか、trust rootはどこか、failure時にinstallを拒否するのかを見る必要がある。