署名を失うことなく開示する

デジタル製品パスポートに表示される情報は、人によって異なります。購入者は公開データのみを確認できます。修理業者や再生業者は、それ以上の情報を確認できます。市場監視当局はすべての情報を確認できます。この点は明確になっており、欧州の規格でも現在では明示的に規定されています。

興味深い疑問は、もっと控えめな点にあります。もし誰かが公開データ以外の保護された項目を閲覧できるようになった場合、その人物は、まさにその項目が本物であることを証明できるのでしょうか？それとも、プラットフォームがそれらを正しく抽出し、変更を加えずに転送したことを信頼しなければならないのでしょうか？

公証人が、手紙全体ではなく、各段落を個別に認証すると想像してみてください。公開された手紙は誰もが受け取れます。それ以上の情報へのアクセス権を持つ人には、追加の段落が提供され、その一つひとつに、同じ公証人の印が引き続き押されています。私たちは、この仕組みに基づいてプラットフォームを構築しました。 ほとんどのプラットフォームにおいて、上記の質問に対する正直な答えは「信頼」です。しかし、私たちの場合は「証拠」です。開示時に初めて追加される各フィールドについて、その証拠を提示します。この記事では、この違いがなぜ重要なのか、そしてなぜ私たちがより手間のかかる道を選んだのかについて解説します。

アクセス規則はすべての人に等しく適用されます

DPPにおけるアクセス権、セキュリティ、機密性に関する欧州規格であるEN 18239では、フィールドごとにアクセスを制御することが求められています。つまり、各フィールドについて、誰が閲覧できるかを定めた規則が存在するのです。これは適切な要件であり、満たすことは難しくありません。 これらの規格がそもそもどのような地位にあるかについては、調和規格に関する当サイトの記事で詳しく解説しています。

これを実現する一般的な方法は、サーバー上のフィルタです。サーバーは、誰がリクエストしたかを把握し、その人物が閲覧を許可されている内容を照合した上で、まさにその部分のみを返します。規格が求めるのは、これだけです。利用者は、サーバーが誠実に選択を行い、伝送中に何も変更していないと信じる必要があります。公開用の情報シートであれば、これで問題ありません。 しかし、リサイクル業者が中古バッテリーの価格設定の根拠とするようなデータについては、あまりにも大きな信頼を求められることになります。

ここには、規格が考慮していない一つの問題点があります。それは、表示されるデータに認証マークが付いていないということです。

最も理にかなった解決策は、データに署名することです。スケールの両端については、通常の署名が有効に機能します。つまり、公開ビューに署名し、完全なデータセットに署名するということです。その詳細な手順については、DPPの「署名と証明書」に記載されています。問題は、その中間部分で生じます。 文書全体に対する署名は、署名時に存在していたフィールドのみをカバーします。権限のある読者に、保護されたフィールドを追加で公開した場合、そのフィールドは署名された範囲外となり、読者に届く際には保護されていない状態になります。 「誰が何を見るか」というあらゆる組み合わせを事前に署名することは、組み合わせの数が爆発的に増えるため、誰も行いません。結局、印のないフィルタに頼ることになり、中間段階は再び「信頼」に帰着してしまいます。

各フィールドを個別に署名する

これよりも優れた仕組みがあり、私たちはこの仕組みに基づいてプラットフォームを構築しています。完成した文書を1つのブロックとして署名する代わりに、作成者は1回の処理で各フィールドを個別に指定します（規格に詳しい方のために補足すると、これはW3Cの規格 ecdsa-sd-2023 に基づく手法です）。

各ビューは、まず同じ公開フィールドから始まります。読者がそれ以外に目にする内容は、フィールドごとに追加されていきますが、それらの各フィールドは、オフラインで、再署名を行うことなく、またビューを組み立てた機関への信頼を必要とすることなく、引き続き作成者の公開鍵に遡ることができます。 権利を主張していないフィールドは、単に存在しません。黒塗りされているわけではなく、そもそも存在せず、それらに関する情報は一切漏れ出ません。

一例：修理業者

ある修理業者が、バッテリーに関して正当な利害関係を申告しました。これは、バッテリー規制で明示的に規定されているアクセスレベルの1つです。 その修理業者のシステムは、自社の鍵を使用して当社のインターフェースにログインし、パス情報を取得します。返されるのは、購入者にも表示されるのと同じ公開パスですが、そこに1つのフィールドが追加されています。それは、権限のある読者のみに開示される「分解手順」です。別の文書でも、特別版でもありません。

その事業者がこの項目を信頼する前に、同社のソフトウェアは、付属のシールをメーカーの公開鍵と照合して検証を行います。検証が成功し、特に追加された項目についても問題がないことが確認されれば、その事業者は、この取扱説明書が文字一つに至るまでメーカーから直接提供されたものであり、その過程で誰も内容を改変していないことを確信できます。 検証に失敗した場合は、そのビュー全体を無視します。ユーザーが受け取るべきフィールドのみを確実に受け取れるようにするのは、当社のアクセス制御の役割です。新しいのは、その次のステップです。届いたものが本物かどうかは、当社に確認することなく、ユーザー自身が検証するのです。

なぜ「破損していない」ことが重要なポイントなのか

封印が破損していないからといって、その内容が真実であるとは限りません。 それは、「製造元がまさにこれを記述しており、それ以来、誰もその記号を一切変更していない」ということを示しているのです。これにより、文書を単に受け渡しただけの者――中間ストレージ、ネットワーク、アーカイブ、そして私たち――は、信頼性の問題から除外されます。

誰があなたにパスポートを渡したかは、もはや重要ではありません。

また、シールは二値的なものです。有効か無効か、その中間はありません。したがって、追加のフィールドがシール付きで届くか、シールなしで届くかというのは、程度の問題ではありません。シールがなければ、その内容が「多少弱く」記載されているわけではなく、そもそも記載されていないのです。

両方の確認方法

どなたでもご ## 自身で確認いただけます。「Transpareo Time Machine」は、製品パスポート用のオープンソース表示アプリです。このアプリは、パスポートのバージョン履歴を閲覧しながら、当社のサーバーに問い合わせることなく、閲覧者のブラウザ上で各署名を再計算します。Tシャツのパスポートには文書全体にわたる署名があり、電池のパスポートにはフィールドごとの承認が記載されています。

どちらも公開されているW3C標準であり、どなたでも実装可能です。 文書全体にわたる署名は、構築・運用コストが大幅に低く、公開データのみを提供する場合でもこれで十分です。「タイムマシン」が両方の方式に対応しているのは意図的なものです。これにより、パスは一般的な標準フォーマットのまま維持され、当社製ツールだけでなく、あらゆる適切なツールで検証が可能となります。

誰にメリットがあり、規格は何を求めているのか

公開データ以外に、一体誰に何が開示されるのでしょうか？ たまたま立ち寄った買い物客ではありません。 それは、使用済みバッテリーパックの価値を査定する処理業者、リスクの価格を算出する保険会社、化学物質を分別するリサイクル業者、事件の立件を行う行政機関といった方々です。つまり、金銭や安全に関わる意思決定を行う読者の方々です。 そして、通常のアプローチでは、まさにその意思決定の根拠となる項目について、認証マークを取得できない読者の方々です。私たちは、認証マークは誰にとっても同じ意味を持つべきだと考えています。つまり、表示されているすべての項目はメーカーから提供されたものであり、それ以降一切手を加えられていないということです。 公開フィールドにのみ付与される認証マークは、不完全なものです。

率直に申し上げますと、これらはいずれも義務付けられているものではありません。EN 18239規格では、アクセス制御が求められており、サーバー上のフィルターによってこれは完璧に実現されています。 公開されたフィールドを検証可能にするのは、私たちが追加で実施している措置です。なぜなら、署名付きパスポートの真の意義は、誰もプラットフォームを信頼する必要がないという点にあるからです。中間レベルを例外として除外することは、まさに署名が排除すべきだった信頼を再び呼び戻すことになります。

同じ原則により、あるフィールドは無視されることになります

各フィールドについて個別に規定することは、もう一つの特徴をもたらします。そして、この特徴こそが、欧州法によって実際に求められているものです。 一般データ保護規則は、個人に個人データの削除を求める権利を認めています。 ブロックとして署名されたデータセットは、自身の署名を破壊することなく、この要件を満たすことはできません。

ここでは各フィールドが独立しているため、個々のフィールドを削除しても、残りの部分は引き続き検証可能です。 万が一、個人データがパスポートに誤って含まれてしまった場合でも、それらは完全に削除され、パスポートは有効なまま維持されます。再発行の必要もなく、履歴が途切れることもありません。法律で保存が義務付けられているフィールドはそのまま残され、削除可能なデータについては、要求に応じて、たとえ数年経ってからも削除することが可能です。

なぜそれが難しかったのか、そして私たちがどのように解決したのか

この手法は私たちが考案したものではなく、W3Cの公開標準規格です。アイデアを思いつくこと自体は難しくありません。難しいのは、10年後もパスポートが検証機能を維持できるように構築することです。 通常の署名は、文書のバイト単位で計算されます。一方、フィールドごとの署名は、個々の項目ごとに計算を行います。そのため、署名を行う前に、パスポートを、各項目が独立した文として記載される固定形式に整えます。 この形式は、10年後も文字単位で正確に再現されなければなりません。そうでなければ、認証が成立しなくなります。これには3つの目立たない課題がありましたが、私たちはこれら3つすべてを根本から解決しました。

数値は型を失ってしまいます。2.0 といった値は、通常のデータ形式を経由すると 2 として戻ってきます。人間にとっては同じ値ですが、固定書式にとっては別の値となります。当社では、すべての値をその型とともに保存しており、型のない数値が 1 つでも現れると、公開処理は直ちに中断されます。

名称だけでは意味になりません。各フィールド名は、辞書内の明確な意味に紐づけられていなければなりません。そうでなければ、変換の際にそのフィールドは黙って消え、シールの適用対象外となります。当社では、すべての辞書がローカルに存在し、ネットワーク経由で取得されることは決してありません。 未知のフィールド名が見つかった場合、署名処理は停止し、黙って空の結果を返すことはありません。

エントリには固定の名前が必要です。当システムでは、ドキュメント内の各エントリに固定の識別子が割り当てられており、毎回新しい補助名を割り当てるのではなく、処理のたびに表記が同じになるようにしています。

最も扱いが難しい部分は、製造元独自の鍵にあります。発行のたびに、公開可能な各フィールドを個別に署名するために、追加の短命な鍵が必要となります。この鍵は製造元自身が生成し、破棄します。もしこの鍵が当方にあるとすれば、後から個々のフィールドをでっち上げることも可能になってしまいます。 各パスポートには、このような2つの署名が付与されています。1つは発行元によるもので、もう1つはTranspareoによるものです。これは、個別に公開されるフィールドに対しても同様です。

私たちにとって、この手間は適切な場所にかかっていると言えます。 各パスポートは公開時に署名され、前のバージョンと連鎖されます。また、パスポートがEU-DPPレジストリに登録されると、改ざん不可能な10年間のアーカイブが有効になります。ブロック全体ではなく各フィールドごとに署名を行うことは、この中核機能の拡張であり、単なる付加機能ではありません。

現在の状況

私たちは、すべての読者に対してその有効性を証明することを選択しました。なぜなら、認証マークは、誰が確認しても同じ意味を持つべきだからです。その仕組みをご覧になりたい方は、上記にリンクされた2つのパスポートの例を、サーバーに問い合わせることなく、ブラウザ上で直接検証してみてください。