マイナンバーカード狂想曲・パスワードレス認証

はじめに

最近、マイナンバーカードのセキュリティ問題でいろいろと騒がしいです。起きてしまったことには迅速に対応するとしても、理解もなくヒステリックに反応するのはどうかと思うのです。マイナンバーカード自体が問題だとの意見も多いのですが、もう少し冷静なってほしいと思います。技術的な問題と運用の問題は切り分けて、建設的な議論をしないと、何も前に進むことはできません。良い機会と捉え、これからのデジタル時代に適した新しいシステムの創造につながって行かなければなりません。

自らは開発には関わっていないのでふわっとした解説資料となってしい大変申し訳ないのですが、それでもマイナンバーカードがPKIを基礎とした優れたカードであるか、そしてPKIのメタファーであるAKIとの相性について考えを共有できれば幸いです。(^^)

人は失敗する／信じる事（トラスト）の限界

私は、問題の根源は、旧来のITシステムにある「人をトラストする」デザインだと思っています。老若男女全てにITを使わせるのであれば、「ゼロトラスト」を前提とした設計に切り替えなければいけません。今のままでは、これからもいっぱい事件が起きてしまう事でしょう。

そもそも、人は「失敗する」ものです。そういった事を織り込んだ設計こそがゼロトラストな設計です。トラストがありきだと、裏切られたら終わりです。信じてたのに裏切られて、開発者全員が大目玉なんて、なんかもう不幸すぎです。今、起きている事件は、そういった問題点を浮き彫りにしています。これからは「裏切られても大丈夫」を前提にシステムを設計する時代に突入したのだと思っています。

どんなトラブルが起きているのか

今、盛んに報道されているトラブルの記事をいくつか拝読しました。
インターネットで知り得た情報からの推察なので、見当違いな発言があるかもしれません。ご承知おきください。(^^;

情報の不整合

コンビニで住民票や印鑑証明などを印刷すると、全く知らない「赤の他人の証明書」が出できた。
保険証とマイナンバーカードが不一致になってしまい、一時的だが「治療費の全額負担」が発生。

情報の関連付け作業を手作業で行った事が原因とありました。とってもオーソドックスな人為ミスです。こういった名前で情報を処理する際には「名寄せ」と言って、それこそ昔からよくある業務です。検査検証のワークフローが甘くて、チェックの漏れが起きてしまったのだと思われます。そもそも、人はしでかす前提なのであって当たり前、起きた時の対処がなされていなかった事に驚きます。やはり、問題として注目すべきは「情報」が個別に守られていない事ではないでしょうか。マイナンバーカードがユーザーの認証にしか利用されていないので、肝心の情報は認証が終われば平文になってしまうのです。もしも、システムの運用セキュリティが突破されてしまったら、全てのデータが漏えいしてしまうこともあり得ます。

システムのオーバーロード

過負荷でシステムがバグってしまい、複合機（印刷機）内に残っていた他者の情報を印刷してしまった。

ちゃんとシナリオを作って負荷テストを実施していれば、事前に検知できたと思います。多分、データに変化を与えずに負荷テストを実施し、事象を検知できなかったケアレスミスだったのではないでしょうか。
昨今は、開発の分業が進みすぎて、運用トラブルまで意識して設計できるエンジニアが少なくなったと感じていました。結果、運用のトラブルを想定できなくて、負荷に弱いシステムを創出してしまう遠因になるのです。オーバーロード発生時は想定もしなかった事象が起きます。そういった時にこそ「情報を守る」意識が必要です。

あいまいなユーザー認証

共用端末で銀行口座を登録する際、前利用者がログアウトせずに次の利用者が操作を行なったため、口座情報が上書きされてしまった。

システムの問題ではなく、運用の問題です。共有端末、ゼロ知識な利用者、公共の場所、という素晴らしくゼロトラストな状況が利用前提にあります。普通のITシステムの様な設計をしたら「そりゃぁそうなりますよね」的なオチです。システム開発においてゼロトラストの運用イメージが欠落しているのがよく分かります。
ゼロ知識な状態なんですから、当人には危険な状態にあったのかなんて認識はありません。公共のシステムには、ユーザーがシステムを理解しているという概念を持ち込んではいけないのだと思い知らされます。

家族口座の割り当て

マイナンバーごとに個別口座が必要。
マイナンバーにはカタカナ項が無い、銀行はカタカナなので名寄せ検証が出来ないので、入金が滞るかもしれない…

バグではなく、設計コンセプトの周知徹底のミスでしょう。マイナンバーカードごとに専用の銀行口座が必要との事ですが、こちらは設計思想のリフレッシュは必要かもしれません。1件１葉で設計すると、後々、困りそうです。電子マネーでの運用もそこそこ済んでいるのに、なぜ今更、国民個別の銀行口座と話が進むのは、あんまりピンときません。
デジタルなのですからキャッシュフローのトレーサビリティの方が、国税が望む資産管理につながると思います。しかしながら、私は、経済の話は門外漢なのでこの辺に留めておきます。

結局は人が原因

センセーショナルな物言いで報道されていますが、実際には普通によくある現場の人為的ミスがほとんどだと感じます。各事象の細かな報告書を読んでいる訳ではないので、あくまでも推測ですが、原因は容易に想像できそうです。
私が感じるのは、マイナンバーカードが持つ特性を活用せずに従来の運用方法でシステムを構築した事だと考えます。だって、初めてのシステムだし、使う人みんな素人ですもの、そりゃぁ失敗しますって。今までのシステムの作り方だと、ちょうどオープンβの段階で、今の様な自体は織り込み済みだと思うのです。一般人を巻き込んだβテストなんですから、いろいろとトラブルはあると思います。
発生した事象を適切に公開して、誰もが納得できるシステム構築に注力すれば良いだけです。そういった取り組みの中で新たな技術が構築されることを願います。

Topics

マイナンバーカード

さて、マイナンバーカードに関係する記事をサラッと読んでみました。そもそもマイナンバーカードとはなんでしょうか。
マイナンバーカードは、個人番号(マイナンバー)を記載した公的な身分証明書です。マイナンバー制度は、税や社会保障などの行政手続きで個人を識別するための番号制度です。このマイナンバーを記載したマイナンバーカードは身分証明書として利用できます。
マイナンバーカードには、氏名や住所、生年月日、性別、顔写真に加えてマイナンバーが記載されています。このカードを使って、税務署や市役所、病院などの行政手続きやサービスを受けることができます。
主な用途としては以下の通りです。

• 税務や社会保障の手続きでの本人確認
• 住民票の写しや印鑑登録証明書の交付申請
• 病院での受診登録での本人確認 他、

将来的には、クレジットカードや銀行口座開設の本人確認にも利用できるようになる予定です。

構成技術

マイナンバーカード利用されている主要技術を紹介します。

JPKIの証明書なども搭載していて、個人でデジタル署名に使えるカードなんですよね。私は、もっとITの他のシステムでも使える様になって欲しいと思っています。

マイナンバーカードの主な運用アクター

マイナンバーカードの運用を考えるにあたり、関係するアクターを整理しておきます。本書では以下の様に取りまとめて、絵図に起こしました。

組織	説明
J-LIS 地方公共団体情報システム機構	マイナンバーカードのシステム運営組織です。 本書では説明簡素化の為に、サービス提供者として取りまとめています。
JPKI	署名用証明書および利用者認証用証明書を保証する認証局です。
利用者	住民票を有するすべての国民 ※ 最低限の注意事項で安全に運用できる事が前提にあります。
事業者	マイナンバーカードを事業に利用したい事業運営者

俯瞰で概要をまとめるために簡素化しました。ご了承ください。

以下に各運用アクターへのリンクを掲載します。

カードの発行

まずはマイナンバーカードの発行を俯瞰します。

マイナンバーカードの利用

マイナンバーカードを使う際には、ICカードリーダーを使って認証します。認証後は特にマイナンバーカードを意識する事はありません。

e-Tax申請では令和3年度はデジタル署名を行って申請したと記憶していたのですが、令和4年度は利用者認証のみで申請に簡素化されていました。利用率向上の対策なんだと理解しています。個人がデジタル署名に触れる機会なのに残念です。

事業者との連携

AKIの説明に合わせてかなり簡素化して表現しています。マイナンバーカードについての参考資料は以下のとおりです。

マイナンバーカードと事業者との連携

マイナンバーカードの事業連携については、利用者認証を使用しないので、通常のICカード運用とさほど変わりません。しかしながら、マイナンバーカード自体には証明書が内包されていますのでライフサイクルが存在します。また、カード紛失などのトラブルに対応する必要があります。そのため、ウェブのサイト証明書の様な運用フローが提供されています。

マイナンバーカードのおよその全体像と、AKIを考える上で必要な技術背景は以上です。

＋AKIを考える

マイナンバーカードの技術的仕様や機能拡張のポイントを押さえる事ができました。
机上ではありますが、今までも活動ノウハウをもって、AKIによるマイナンバーカードへのAKIの組み込み案を説明します。マイナンバーカードを例にゼロトラスト運用への提案につなげます。

構成技術

マイナンバーカードの改変は一切不要です。空き領域にKeyCaseを導入します。

事業者APは事業者ごとに用意する前提でしたが、AKIのKeyCaseでは利用者単位で発行することになり、この点が運用面での大きな差異となるかもしれません。AKIのKeyCaseは利用者ごとに用意されるため、事業者連携においてマイナンバーカードそのものをAKI認証に利用します。すなわち、事業者連携においてもマイナンバーカードを使ったKeyCaseによる利用者認証がその都度、行われます。

運用アクターの再定義

組織	AKIでの役割	説明
J-LIS 地方公共団体情報システム機構	読み手	便宜上AKIの持ち手サービスの役割を設定しました。SureArchiver相当機能のサービスを提供します。
JPKI	–	AKIは公開鍵は使用しないので、役割はありません。
利用者	作り手、マイナンバーカードの持ち手	KeyCaseの作り手および持ち手となります。作成したKeyCaseはマイナンバーカードの空き領域に保存されて運用利用します。格納にあたり耐タンパー特性は不要でも問題ありません。 事業者連携用の個人情報アーカイブ（暗号オプション付き）の作り手になります。
事業者	持ち手	個人情報アーカイブの持ち手です。マイナンバーカードの認証時にアーカイブファイルの検証で利用者認証を行います。

カード発行後の初回設定

マイナンバーカードの発券プロセスは従来通りです。AKIでは初回接続時にKeyCaseの発行を行い、発行されたKeyCaseをマイナンバーカードに格納します。PoC（SureArchiver）では任意のPCフォルダーへ保存する手順としていましたが、非常にスマートな保存先としてマイナンバーカードが利用できます。これはAKIの設計においてICカードを使った所有物認証として有益です。

AKIのアプリケーションモデルとしては作り手が利用者、読み手がJ-LIS、持ち手が利用者のマイナンバーカードです。作り手である利用者に永続的なアクセス制御が残り、検証鍵の流通がないので読み手が所有する検証鍵のライフサイクル管理は不要です。
KeyCase自体はどこに保存しても問題はありませんが、マイナンバーカードの対タンパー特性が唯一性の強化に役立ちます。AKIをデザインした私としては、もとより要望していた構成です。

マイナンバーカードの利用＋AKI

続いて、ゼロトラストを施行した提案です。マイナンバーカードのKeyCaseをを使って、サービスサイトにある個人情報のゼロ知識暗号を利用する事ができます。

運営側の情報を適切に処理する事でゼロトラスト運用が実現できれば、さまざまなコストの削減と効率向上を狙う事ができます。セキュリティ教育のコストを下げ、運用を簡素化し、運用の固定費を大きく削減する事ができます。

事業者との連携＋AKI

利用者認証が事業者連携にも利用できるので、より簡単にシステム連携が可能です。事業者の審査はもちろん必要ですが、従来用意していた事業者APは不要です。利用者が作り手として個人情報をAKI Archiverでアーカイブし、持ち手である事業者サービスに預け、必要な時に持ち手に検証依頼する事で、利用者認証相当の処理が行えます。

連携の視点でも、ゼロトラストを指向した設計は有効です。

人は失敗する／ゼロトラストによるリカバリー

「人は失敗する／信じる事（トラスト）の限界」で取り上げた、お騒がせ事件への＋AKIの効果について、少しお話を広げたいと思います。必ずしも完全な解決策というわけではありませんが、AKIを使って作り手/読み手/持ち手モデルを持ち込む事で、どの様な効果があるのかを文章に起こしました。

情報の不整合

コンビニで住民票や印鑑証明などを印刷すると、全く知らない「赤の他人の証明書」が出できた。
保険証とマイナンバーカードが不一致になってしまい、一時的だが「治療費の全額負担」が発生。

そもそもの最初の入力ミスに関しては、正しく検査フローの運用を徹底するしかないと思いますし、昨今のAIを使って、人の名寄せ自体をシステムを置き換える対策が中心です。それはこれからも変わらないでしょう。そうやって厳格に正しい券面情報が構築できれば、以降の情報セキュリティに対してAKIは効果的に機能します。AKI Archiverで保護された情報を、直接交換する事で、コピーミスや入れ替えなども、容易に克服できます。なぜなら作り手のアクセスコントロールは永続されるので、認証できなければ被害は発生しません。結果、守るべきもはマイナンバーカードそのもの集約する事ができ、リスクが集約できれば、それだけセキュリティも強度も高まります。

システムのオーバーロード

過負荷でシステムがバグってしまい、複合機（印刷機）内に残っていた他者の情報を印刷してしまった。

AKI Archiverで保護された情報は、本件の様な事象にも効果的です。この様な大型の複合機自体、とても高度なセキュリティ機構を持っています。印刷する直前までをAKI Archiverでやりとりし、セキュア印刷するその時にマイナンバーカードの認証を行い、AKI Archiverの認証と複合とを行う事でセキュアな印刷が実現できます。もしも受け取った情報の認証が出来なければ復号されないので漏えいもあり得ません。

曖昧なユーザー認証

共用端末で銀行口座を登録する際、前利用者がログアウトせずに次の利用者が操作を行なったため、口座情報が上書きされてしまった。

AKIを組み込む事で利用者認証＋専用鍵によるゼロ知識暗号が追加されます。もしも、ログアウトせず、マイナンバーカードの再読み込みが不要なシステム設計を行ってしまったとしても、情報を暗号処理する時に鍵が異なってしまうため、復号できない自体に陥るだけに被害を止める事ができます。

ゼロトラストを織り込んだシステム設計

マイナンバーカードにAKIを組み合わせる事で、利用者ごとに個別にゼロ知識暗号を活用する事ができます。ゼロ知識暗号は、名が表す通り、利用者に知識を求めません。それはITリテラシーが低い方にも安心してセキュアな情報活用をいただく事が可能ですし。IT知識を悪用する輩にとっても最大の防壁として機能します。結果として、さまざまなユーザーがひしめくゼロトラストなインターネットにおいて、効果的な運用を実現する切り札になりえます。

こんな記事を見かけました

こんな記事を見かけました。

大抵のシステムでも同じ様な条件は記載されていると思います。「故意又は重過失によるものである場合を除き」とあります。現に、問題はシステムそのものに起因するものではありません。利用者が「丸投げを選んだ」ので「責任が取れない」状態を作ってしまったのが問題です。利用者の視点では、放っておくと責任取れない状態に陥りますよ「至急、確認して！」と促すのが前向きな議論の醸成にならないでしょうか。私的には、どうやってもチェックに穴ができちゃうのはいたしかたないので「ゼロトラスト」で「漏れても大丈夫」な新しい発想をシステムに盛り込んでいければいいのになと思います。この記事からは、安全なフラット型が実現できたら「デジタル後進国」から「デジタル先進国」にランクアップするとも読めます。国民の信頼を得られる様頑張って欲しいです。

まとめ

マイナンバーカード関連のさまざまな報道から、マイナンバーカードの特徴を検討し技術的な特徴を確認し、AKIによるさらなる発展への提案を記事として起こしましたがいかがでしたでしょうか。私自身もマイナンバーカードの実際の案件に関わる事ができず、関連事業に参加している方のコメントや、配布されている資料から、推測して記事を起こしました。ですので、話半分で読んでいただき、AKIの特徴をつかんでいただければと存じます。しかしながら、私自身もIoT関連のエンジニアでしたし、根本技術はPKIなので、さほど大きくは外れていないと確信しています。もしも、この記事が実業に少しでも引っ掛かかれば、その際には、ぜひともご連絡ください。

SureArchiverのソースコードは一式あります。ちゃんとAWS上で稼働します。基礎構造の実証実験も完了しています。(^^)/