捺印デバイスが発表されました！・パスワードレス認証

アイキャッチ・画像：みつ

はじめに

ブロックチェーンを認証局代わりとした電子認証のプロジェクトに従事していた時、その活用領域としてIoTを見ていました。ですが、技術的知見が至らず事業そのものからも離脱しました。その後、GFS社の助力のもと、相互押印という技術を創出、PoC検証を終えて脱PKIが可能であることを実証しました。
しかしながら、PKIの影響が強く、AKIの説明がうまくできません。そこで、まずは技術資料の充実すべく本サイトを立ち上げました。でも、どんなに記事を書いても、やっぱり難しいですよね非対称鍵暗号っていうのは…(^^;
そんな折、一つのインターネットニュースを受け取りました。なんと電子印鑑！の発表です。所有物認証のわかりやすい例として「印鑑」を意識していたのですが、現物を開発していた方がいた事に驚きと羨望を感じます。この様な、新しいことへの挑戦は、挑戦できる企業風土と、それを認める経営陣が支えなければ具体化は不可能です。商品として発表するまでには大変な苦労があったと思います。私的に「妄想上等」で、新しい認証デバイスとAKIとの連携を考えてみました。

KEYMOについて

ハンコ型電子印鑑「KEYMO」の紹介です。本書では「捺印デバイス」と呼称します。

操作も至極直感的で、誰にでも使えそうです。

シンプルです。素晴らしい！
これらの一連の操作を、本書では「捺印操作」と仮定義しています。
本書では、ネットに公開されている情報から仕組みを推測します。詳細を知ることはできませんが、ある程度想定して明文化しておかないと、記事が書けませんので…(^^;

押印と捺印の違いについて

押印は「記名押印」を省略した言葉です。名前を書き示す方法について自筆である事を求めません。対して、捺印は「署名捺印」を意味し、自筆による署名にハンコを押す必要があります。ハンコは本来、作成する書類が作成者の意思に基づいていることを証明するために用いられます。そのため、自筆署名が必要な捺印のほうが、法的な証明力が高いとされています。実際、印鑑証明書が必要とされる契約などにおいては、多くの場合で「署名捺印」が求められます。KEYMOでは自筆署名の画像を利用できるので捺印が可能なデバイスなのです。

ByStamp KEYMO™について

「ByStamp KEYMO™」ですが、2018年にフランスで開発されたハイテク製品です。どこの国でも印鑑は重要なんですね！
2020年にはCESラスベガスにおいて、「イノベーション・アワード 2020」を受賞しています。「欧州のeIDAS規則条項」に従った電子署名手順が適用されるとのことですので、実際の署名付与にいたる手続きにこそ本製品の真骨頂があると理解しています。
本書では、「BYSTAMP®」やeIDAS規則条項といった、捺印に直結するテクノロジーに関しては触れておりません。
AKI活用をテーマに、現存する商品を例に実現可能であろうをユースケースを考察したものです。ByStamp KEYMOの解説ではなく、あくまでも仮定のシステムですので、ご承知おきください。もしも、KEYMOの本来のシステムと大きく違う様でしたらアドバイスをいただければ幸いです。よろしくお願いいたします。

システムの考察

それでは、まずは、どんなシステムなのか、公開されている仕様を元に、自分だったこんな感じで作るかな？的に考察します。

システム構成

動画や公開されている資料から、システム構成図を推測してみました。

KEYMOのサイトでは紹介動画も上がっています。ので、実際に見てみると理解が進むと思います。
マニュアル動画を確認すると、大きくは2つのフェーズに分かれます。一つは捺印デバイスの「アクティベート」そして捺印操作です。デバイスのアクティベートは、以下の手続きです。

デバイスのアクティベート

アクティベーションの操作ステップを以下にまとめます。

1. 捺印操作にて、タスク「捺印デバイスのファームウェアを更新」を実行
2. アカウント情報の設定
   • 名前、所属、メアド、アカウントパスワードなど、一般的なユーザー情報の設定です
   • 入力したメールアドレスへ招待メールを送り、メールアドレスの有効性を確認します
3. 印影画像や自筆署名画像など捺印に使用する情報、およびPIN情報を設定
4. 捺印操作にて、タスク「デバイスへ捺印用情報を設定」を実行

資料をもとに、シーケンス図を想像してみました。

以上で捺印デバイスと捺印サービスが関連付けられました。以後は、普通に捺印を行えます。
捺印は以下の手続きです。

資料への捺印

1. 捺印したいドキュメント（PDF）を選択し、捺印場所を指定
2. PINを入力
3. 捺印操作にて、タスク「ドキュメントへ捺印」を実行

こちらもシーケンス図を想像してみました。

やはり、要所で行われる捺印操作が押印処理のキモになりそうです。
この押印操作を行うことで、実際には捺印デバイスとスマホとがどの様に情報交換すのか、思考実験を進めます。

ByStamp KEYMOの処理フローは未公開です。前出のフローは、あくまでも私の知見を元に推察して作成したものです。
一部、推測や想像ですが、非常に面白いデバイスです。いろいろな気付きが得られて思考するだけでも本当に面白いです。

捺印操作

さて、捺印操作から、およそ、以下の処理を想像できます。

1. 捺印デバイスとスマホをBluetoothで接続し、捺印デバイスの操作ボタンを押下
2. 光通信によるスマホから捺印デバイスへの情報送信
   1. スマホ側で使い捨ての共通鍵を作成する
   2. スマホ画面に捺印デバイスを押し当てる
   1. スマホから捺印デバイスへ光通信にて共通鍵を送信
3. タスクの実行
   1. Bluetooth通信を使って捺印デバイスと相互通信
   2. 通信のペイロードは共通鍵で暗号化

以上、光の明滅で情報を交換すること、スマホにセンサーを押し付けること、で情報交換を行います。本書では、勝手ですが「光通信認証」と呼称しています。

❶ 捺印デバイスとスマホをBluetoothで接続し、捺印デバイスの操作ボタンを押下

アプリケーション自体は、光通信認証後は、事前にペアリング済みとなっているBluetoothを利用します。
Bluetooh通信はペアリングとボンディング（ペアリング鍵の保存）で保護することができますが、広く普及しているので盗聴の可能性があると考えた方が良いと私は考えています。
光通信認証を導入する事で、そういった懸念を払拭できます。操作ボタンを押すことをトリガーに都度の光通信認証が行われることで、高いセキュリティを捺印デバイスとのBluetooth通信に提供することができます。

❷ スマホから捺印デバイスへの情報送信

特徴的な操作として、実際の押印を模した、スマホ画面に「印面（光学センサー）を押し付ける」操作があります。この操作にて、非常に近接された状況を作り出し、液晶の明滅を使って情報を送信するわけです。印面が画面を隠す効果もあり覗き見られてしまうリスクも低く抑えられます。
「押印の所作による目隠し効果＋超近接通信＋使い捨ての共通鍵」これらで、押印デバイスとスマホには必要十分なセキュリティが確保されています。

併せて、光通信の性能面での補足を記しておきます。光センサーが明滅を読む事で情報を伝達するので、スマホから捺印デバイスへの送信しか行えません。また、液晶の反応速度に機種特性があるので、あまり高速な送信は行わない方が無難です。一般的なスマホ液晶では、5ms程度の反応速度との事なので、200bps程度の通信速度を想定しておくと問題はなさそうです。それでも、10秒で2KB程度の転送が可能です。共通鍵は16桁もあれば十分な暗号強度が得られますから、使い捨て共通鍵がちょうど良いのではないでしょうか。本書では、この一連のやり取りが光通信認証の処理ではないかと考えます。

❸ タスクの実行

光通信認証が終われば、あとはシェアした共通鍵を使って、スマホにて指定されたタスクを処理するだけです。タスク自体はBluetooth通信を使って情報交換します。Bluetoothの通信ペイロードは、使い捨ての共有鍵で守られているので、盗聴などを意識する必要がありません。

タスクの実行で行われている事

捺印操作が完了すると、続いてタスクが実行されます。公開資料に記載されているタスクは以下の通りです。

1. 捺印デバイスのファームウェアを更新
2. デバイスへ捺印用情報を設定
3. ドキュメントへ捺印

それぞれのタスクを深掘りします。

❶ 捺印デバイスのファームウェアを更新

情報の流れは、スマホから捺印デバイスへ、です。
捺印デバイスのファームウェアを更新します。初回接続時はセキュリティとしては非常に重要なタイミングです。出荷してから起動されるまでに、幾多の脅威にさらされてしまった可能性があります。ですから、初回接続時にファームウェアを更新する事でリスクを回避する効果が期待できます。また、このタイミングで捺印デバイスのSNを確認し、ブラックリスト確認などの対策もあるかもしれません。ペイロードが暗号化されているので、改造ファームの無効化や、ファームの抜き取りにも耐性があります。初回導入時にこのアクションを組み入れておく事で、将来的な対策にも応用できます。IoTデバイスのセキュリティにおけるデザインパターンだと考えています。

❷ デバイスへ捺印用情報を設定

情報の流れは、スマホから捺印デバイスへ、です。
スマホに入力された捺印画像や署名画像は、「捺印情報」として取りまとめられ、PINをパスワードに暗号処理が行われます。暗号処理を行った捺印情報を、Bluetooth通信を使って捺印デバイスへ送り、処理は完了です。

❸ ドキュメントへ捺印

情報の流れは、捺印デバイスからスマホへ、です。
捺印デバイスから取り込んだ捺印情報は、PINで復号した後、捺印サーバーに送付されます。PINで複合できなければ、処理終了です。シンプルですね。利用者ならPINという秘密を知っているのを利用したシンプルな認証形式です。
サーバーサイドに送られた印影は、ドキュメントへの押印処理に回され、必要ならば「AdobeSign」等をサーバーサイドで施行します。

捺印デバイスの堅牢性について考察する

最後に、捺印デバイス自身の堅牢性について深掘りします。
公開されている資料からは、捺印デバイス自体のセキュリティについては情報を知ることはできませんでした。しかしながら、捺印操作にて、要求仕様には十分なセキュリティ施策が施されていると理解しています。

ByStamp KEYMO™のセキュリティレベル：CC EAL5+

ByStamp社のサイトを確認しました。詳細はやはり明記されていませんでしたが、IoTセキュリティとしてEAL5+と記載されていました。多分　CC EAL5+（Common Criteria Evaluation Assurance Level 5+／評価保証レベル5+）に則したセキュリティレベルでしょう。
確かなセキュリティを設計レベルから行なった製品なのです。やっぱり素晴らしいデバイスですね！
CCの細かな評価は、以下のIPAのリンクをご参考ください。

IPAの資料から読み解くに、TOE（多分TCP Offloading Engine）改ざんが中心なので、認証デバイス視点で考察するとBluetooh通信の改ざん対策としてEAL5＋評価を行っているのでしょう、これが（私が勝手に言っている）光通信認証のセキュリティレベルだと思われます。ですから、耐タンパー特性は対象外としているのではないでしょうか。
余談ですが、このアメリカ国防総省納品の為のCC評価ナレッジを管理するシステムを、NeXTSTEPで開発するプロジェクトに携わった事があります。って書くとなんか凄そうですよね。(^^;

＋AKIを考えてみる

最初にお断りしていますが、本書はあくまでも「私が勝手に推測から起こした」記事です。
AKI連携に関しては、ヒット株式会社様への問い合わせなどは行わない様お願いいたします。

KEYMOのキモである欧州準拠のeIDAS規則条項は完成されているものであり、AKIがどうこうする要素は全くありません。
本書では、AKI（非対称鍵暗号基盤）を捺印デバイスとマッシュアップする事で、新しい認証バリエーションができないかという提案資料です。

AKIは今までにない非対称鍵暗号の基盤技術です。もとよりKEYMOの様な捺印デバイスを想像してまして、多分、とてもAKIを導入しやすいシステムだと考えています。そこで、AKIで積み上げたさまざまな技術とのマッシュアップを考えてみました。私が考えていた「これからの認証デバイス」の具体的なイメージです。妄想かもしれないけど、これからのコトを記事に書けるデバイスが発表されてたことを嬉しく思います。

捺印システムとAKIとのマッシュアップ

今回、すでに稼働している捺印サービスのシステムについて、私なりの考えでシステム構成を想像しました。
この章では、さらに大胆に、この捺印サービスにAKIをマッシュアップするという冒険を行います！
ここから以降は、あくまでもAKIのPoC成果をもとに、こんな捺印サービスが構築できるのではないか！を前提としています。
早速、捺印サービスにAKIを組み込んだシステム概要を作成しました。

捺印サービスのアカウント管理は継承し、AKIを機能追加する前提にしています。
ですから、現在の捺印サービスと同じく、スマホと捺印サービスとはメール認証済みのアカウントでログインされている事が前提になります。
また、SureArchiverサービスと同等の初期処理が行われ、KeyCaseが割り当てられ、AKI TLSによるE2E通信が組み込まれている想定としています。こちらの統合には一般的なWebサービス開発技術で十分に実現可能です。

KeyCaseの生成と保存

捺印サービスへのアカウント登録が完了したのち、初回のサービスアクセスの際にKeyCaseを作成する事になります。
生成後はスマホのメモリーに保存しておくイメージです。概要を以下に図として起こしました。
AKID、AKI TLS専用鍵、バッジ署名鍵がKeyCase（バッジサポート）で管理されるAKIの主要鍵になります。

KeyCaseは、SureArchiverの形式で作成しているので、特にセキュリティを意識する必要はありません。再発行はできない仕様なので、ユーザーが適切に保存する様に運用を設計する必要があります。

関連資料

PIN不要の捺印操作

まずは、捺印デバイスへの応用です。これは、言うまでもなくPIN情報の撤廃です。PIN入力が廃止されれば、捺印デバイスとしての機能性が高まります！
既存のシステムにAKIの主要技術を組み込んでPIN暗号をAKI認証バッジの署名鍵でAKI署名＋暗号オプション（AKI Archiver）を作成するのです。
AKI Archiverを作成する事で、署名情報へのデジタル署名とゼロ知識証明による暗号処理が施され、PINが不要となります。

署名情報からAKI Archiver（AKI署名＋暗号化オプション）を作成

AKI Archiver（AKI署名＋暗号オプション）の構造

AKI Archiverで作成されるデータ構造は以下のとおりです。捺印デバイス用の署名鍵から、署名情報自体の暗号処理までの関係が読み取れるかと思います。

補足ですが、AKIでの署名鍵はPKIの秘密鍵とは異なり、公開鍵情報を持っていません（公開鍵を再取得できません）。もちろん、AKIDから推測することも不可能です。

ドキュメントへ捺印・スマホで復号する

AKI Archiverなのでゼロ知識証明で複合する事ができます。KeyCaseの認証が終わっていれば、捺印サービスとのAKI TLSが完了し、手元にバッジ用の署名鍵（図では紫色）が入手済みになっています。捺印デバイスから取得した署名情報／AKI Archiver（AKI署名＋暗号化オプション）を検証すれば印影画像および署名画像が復号されています。あとは、既存のワークフローに流せば捺印は完了です。

PINとは異なり、AKI Archiverによる署名情報のやり取りは、もう一つ大きな効果をもたらします。それは、署名情報の真正性です。AKIArchiverが提供するAKI署名＋暗号オプションにより、復号した署名情報の原本性はPKIによるデジタル署名と遜色ありません。

ドキュメントへ捺印・捺印サービスで復号する

捺印デバイスから取得した捺印サービスでバッジ用検証鍵を管理しているので、署名情報／AKI Archiverを直接捺印サービスに送るだけでもワークフローが成立します。

スマホとの光通信認証とBluetoothにて既に捺印デバイスの信用は確認できています。そしてデバイスから受け取った捺印情報の展開手段を知らない前提条件があるので、捺印処理のセキュリティをさらに強固にします。

捺印デバイス自体の強化は必要？

IoTに詳しいクラッカーであれば、物理的にメモリへアクセスし情報を抜き出してしまう事もありえます。
幸いにも、AKIは情報自体がゼロ知識認証をパスしない限り複合できないので、耐タンパー特性は不要と言えます。
これは、秘密の管理を前提としていた従来のIoTセキュリティに対する福音です。

耐タンパー特性とは、機器やシステムにおいて、データや動作などを、外部から解析や改変されることを防ぐ能力のことです。
リバースエンジニアリングや、ハードウェアの分解や解析など、さまざまな分析方法からの防衛能力の事です。

関連資料

デジタル落款印

本来の目的が捺印だったので、サービスサイドのワークフロー連携も交えた使い方を前章で提案しました。
実は、元々は公式バッジの活用から、本書のアイデアにつながっています。捺印デバイスは「公式マーク（認証バッジ）のサポート提案・Badge Support」と相性が良いと考えています。公式マークの保管場所、そして実行アクションといった、ユーザー主体の認証アクションにデジタル署名技術をわかりやすく展開できるのではないでしょうか。ユーザー主体の認証アクションを印鑑文化に求めると「落款印」が近しいかと思い、落款印を題材にワークフローを考えました。

落款印（らっかんいん）とは書・絵画などに押す印鑑の事です。 落款とは「落成款識（らくせい-かんし）」の略で、作品が完成した際に作者が署名・捺印する事を指しています。

単純に、デジタル情報をまとめて落款印／AKI Archiver（AKI署名のみ）を作るイメージです。（情報のまとめ方は、本書では言及しません）
落款印も情報も一緒に配布します。情報の受信者は受け取った情報の配布に落款印を捺印サービスに問い合わせして、真贋確認を行うイメージです。落款印を検証する事で、改ざん検知やトレーサビリティの検証が可能なので、大きな社会問題となっているフィッシング詐欺の根本解決にもつながります。将来的には、マイナンバーカードなどの公的デジタル署名を使った実印運用などもあります。

AKI Archiver（AKI署名のみ）の構造

落款印の場合は、デジタル署名で完結しますので、署名対象となるデータ自体は暗号処理を施さない方が良いと考えています。AKI Archiverにはデジタル署名のみをサポートするフォーマットも用意していますので、ご参考ください。

関連資料

ユーザー認証デバイス

KeyCaseは、認証用の情報は、任意な場所に自由に保存する事ができます。捺印デバイスを、KeyCaseの保存先に利用する事で、FIDO認証の様な所有物認証に活用する事もできます。保存には、捺印デバイスとスマホの相互認証が必須なのが、所有物認証の面でも有効に働きます。ですから、ユーザーは適切な機器とBluetooth認証さえできていれば、あとは手元に捺印デバイスがあるだけで所有物認証が有効にできます。これは結構便利だと思うのですが、いかがでしょうか。
拡張のためのステップも簡単だと考えます。アカウント初回接続時にKeyCaseを生成したのち、捺印デバイスに光通信認証後に送付するだけを想定しています。

捺印サービスへの認証時は、Bluetooth通信にてKeyCaseを取得し、AKI署名認証を行う流れとなります。KeyCaseの取得にあたっては、スマホとの Blurtooth接続が完了していれば、毎回の光通信認証は不要と考えています。もちろん、形式的に光通信を行うのも、統一感があるので、組み入れても良いでしょう。

SureArchiverではKeyCaseの保存先をユーザーの判断に委ねるので、できれば保存先としての現物が欲しいと考えていました。捺印デバイスは、ドンピシャなデバイスだと思っています。所有物認証として保存デバイスがあると直感的で分かりやすいシステムとなります。バックアップやコピーなどもより簡潔に指導できると確信しています。

関連資料

情報資産の封印

捺印デバイスをSureArchiverの鍵デバイスにする事で、情報の取りまとめが革新できるのではないかと思っています。PoCではSureArchiverのアクセス管理はアカウントに任せていました。例えば、アーカイブファイルの作成、展開、検証の各ワークフローのアクションデバイスに捺印デバイスを割り当てると、アナログな使い方をしながら、高度なデジタル情報管理システムが構築できるかもしれません。
会社の情報一式を捺印デバイスでパッキングし、移動、コピー、配布を自由に行えます。配られた情報は、適切なアカウント、あるいは捺印デバイスでのみ検証し展開できるのです。そして、作り手は、いつでも自由に、大元の捺印デバイスを使って、論理的な抹消が行えるのです。まさしく、手元にある捺印デバイスが、情報アクセスの根源となり、高い付加価値を持つ事ができます。結構、SFチックな話に聞こえるかもしれませんが、PoCで実証実験は済んでいるのは大きいと思っています。
持ち出しの承認を捺印デバイスにする事で、セキュリティリテラシー教育を低く設定する事が可能です。開梱には捺印操作が必要なので、配布後もトレーサビリティを追える点も重要です。さらには、SureArchiverはアクセス制御が永続的に行えるので、いつでも無効化が可能です。
そして、配布手段に関しては、レガシーな安価なメディアを使う事ができるのも、ポイント高いと考えています。(^^)/
例として、持ち出しゲートウェイにて捺印デバイスで持ち出すイメージを書いてみました。

封印するというイメージも直感的で分かり易いと思います。
例えば、デジタル資産を取りまとめ、アーカイブを作成し託す操作を考えてみたとしましょう。
デジタルに疎いお年寄りにあっても、封印した事や、封印に使った捺印デバイスの重要性は、直感的に理解してもらえるのではないかと思います。

関連資料

デジタル実印

捺印デバイスをSureArchiverの鍵デバイスにする事で、情報に唯一性を与える事ができます。これまでの捺印デバイスは、あくまでもデジタル署名の作成でした。これは、情報に改ざんがない事を証明しているに過ぎません。（改ざんされていない事：真正性）
SureArchiver（非暗号オプション）でアーカイブしたファイルは、相互押印技術によって唯一性を提供します。唯一性を持つアーカイブファイルは、そのアーカイブ情報内容が唯一である事を保証することができます。

実印とは、市区町村の役所に登録した、公的に認められたハンコのことをいいます。 役所にハンコを登録することを印鑑登録といい、登録されたハンコを実印と呼びます。 印鑑登録をすると、印鑑証明書を取ることができます。

「図 22. 唯一の証が捺印された証書」の図中にある「Hashハッシュ（紫色）」について補足します。
捺印デバイスに設定した、バッジ署名鍵のハッシュ値です。役所発行の印鑑証明書との付き合わせに使用するイメージです。

SureArchiverの特性として、証書の作成にサービスが関与しないのも、大きなポイントです。証書に押印した利用者が作り手であり、サービスはあくまでも読み手に徹する事になり、捺印デバイスのセキュリティとしての価値を高めます。SureArchiver形式のデジタル認証にマイナンバーカードの様な公式の証明書と組み合わせることで、捺印デバイスに実印としての役割を与えられないかと考えています。本書の「印鑑証明書」にて、AKI以外のシステムとの連携案を（草案レベルで恐縮ではありますが）作成しました。一読いただければと存じます。

PDFフォーマットを情報コンテナとして活用する

PoCでは情報のコンテナフォーマットにtar形式を採用しました。設計上はコンテナフォーマットは自由に選択できます。例えば、コンテナフォーマットをPDFにすれば、唯一性を持つドキュメントとして活用する事も可能です。唯一性の検証は、必ずSureArchiverサービスが必要となるので、検証操作を確実に追跡する事になり、正確なトレーサビリティが取得できます。トレーサビリティが得られる事で、作成する証書（PDFファイル）の「フォレンジック」を支援する環境構築にもつながります。
SureArchiverの将来拡張としてぜひ検討したい機能です。

フォレンジックとは、不正アクセスやその他のサイバー攻撃によって被害を受けた企業や個人が、法的証拠を押さえるために実施するデジタル的な鑑識だと理解しています。

この章で提案している捺印は、デジタル落款印やAdobeSignなどで使われている文書へのデジタル署名とは異なります。AKIが提唱する「作り手／読み手／持ち手モデル」に基づく新しいデジタル署名です。今後、PoC検証などを行なった後に改めて「デジタル実印の実現」として成果をご報できればと考えています。

関連資料

印鑑証明書／デジタル実印の補足

捺印デバイスにおける印鑑証明書について一考しました。十分に考察はできていませんが、既存インフラを十分に活用できているのではないでしょうか。
印鑑証明書の運用は、既存の大規模システムが稼働中なので、AKIが導入できない前提で考察しました。AKI前提ならもっと簡単なのですが、仕方がありません。(^^;

マイナポータルへ登録

マイナンバーカードを使って、捺印デバイスに公的な与信を設定します。

マイナンバーカードを使った認証サービスを流用して捺印デバイスの与信に利用するイメージを、ベースに考察しました。
マイナポータルへの登録ステップは以下の通りです。

マイナポータルへの個別情報の設定は未調査です。図にあるHash情報などの事業者情報の預かり方については、最適な手段を調査する必要です。より良い仕組みなどがございましたら、ぜひ、ご教示ください。

印鑑証明書の印刷

マイナポータルから印鑑証明書を印刷し、捺印デバイスを実印として運用をしたい事業者に提出します。

マイナンバーカードを使ったコンビニ印刷は、出力した紙自体に物理的な与信がついています。この、コンビニ印刷に印影と併せて「印鑑証明用のハッシュ値」をQRコードで追加印刷するイメージです。
重要ポイントは以下の通りです。

• 流通している情報は、ハッシュ値のみ
• マイナンバーカードの与信付きサービスに登録
• 事前に提出済み

実印として登録

あとは事業者サービスにて捺印デバイスを実印登録するだけです。
登録ステップは以下の通りです。

SureArchiver自体には署名鍵の更新は不要です。マイナンバーカードの秘密鍵を使用していないので、カードの定期更新も影響しません。従来の印鑑と同じ様に、末長く利用できる捺印デバイスになりそうです。もちろん、長期の運用やデーターベースのメンテナンス対策も、AKIはバッチリ考察済みです。

まとめ

いかがでしょうか。
捺印デバイスが情報資産そのものを管理するキーデバイスになりえる可能性を示せたと思います。古来より活用されていた「印鑑」による運用を、捺印デバイスとゼロ知識認証でデジタル世界に再構築します。長い歴史を持つ捺印文化を新たにリスタートする提案といたします。本記事にて、捺印デバイス、そしてAKIという新しい技術、に興味を持っていただければ幸いです。