はじめに
※本記事は2枚カード方式のメインとなる設計記事です。
この概要は、
Card1（本人を証明するカード、自動で認識される存在証明カード）、
Card2（権限情報を持つカード、提示して使うカード、多階層的に権限を入れられる）、
スマホ（管理とカード作成・追加認証のための補助デバイス）
以上の三つを組み合わせた、新しい認証の仕組みを説明するものです。
これは「スマホ1台に全部をまとめる」方式の逆で、
あえて現在のスマホの役割を分けることで、強く・使いやすくするという発想です。
多くの認証は「秘密鍵をスマホに置く前提」で設計されているため、
端末紛失・乗っ取り・OS依存 といった問題を避けられません。
本方式は、この前提を覆す “秘密鍵を端末に置かない実世界での認証方式” の提案です。
本方式では、本来は１つであった本人確認と権限確認という要素を分割して２つのカードに入れ、お互いが承認することで初めて認証を安全に行う仕組みにしています。
これは、秘密分散法 の考え方を取り入れつつも、
本人性と権限を独立させて物理的に分離し、秘密情報を再構成・復元することなく
2枚のカードの相互承認によって認証を成立させる構造です。
これは情報の復元の処理過程を行わず、その痕跡をどこにも残さないためです。
また、使用する2枚のカードは、盗まれても重要な個人情報などは入っていない状態にあり、
どちらか1枚を紛失しても使用できませんし、スマホなどを使って直ぐに再発行できる
構造になっています。これはゼロトラストの考え方そのままです。
使用者が実際に行うことは、今までと同じようにカードを1枚提示して使うことだけです。
また、最新の認証技術である パスキー は サービスログイン鍵 の一種であり、
この方式では Card2 に配置する要素のひとつになり得ます。
つまり パスキー をICカードで運用できる構造にしています。
この構造は新しいものですが、パスキーのデバイス依存という弱点を補いながら、
セキュリティをさらに上げ、カード2枚（提示は1枚）だけで手軽に使えるようになるのは
パスキーをより広く普及させるものとして有効なのではないかと考えます。
基本的には本認証方式はパスキーより上位の構造（本人性と権限の分離）を扱うものですので、パスキーと競合するものでもありません。
本システムは、暗号強度を上げたり高価なハードウェアでセキュリティを上げる方式では
ありません。できるだけ安価なパーツを使って、高度な攻撃方法にも対応できる構造を
作ることで、高い安全性を得るものとして設計しています。
今のところ必要なのはICカード2枚（自動化により提示は1枚）とスマホだけです。
本方式のセキュリティ強度は、暗号鍵の長さや計算量の増大によって得られるものでは
ありません。認証が成立する過程において、攻撃対象となる秘密情報や権限情報が構造的に
存在しない状態を作り出すことで、多くの高度な攻撃手法そのものを成立させません。
無いものは攻撃できないという考え方です。それがトラストアーキテクチャだと思います。
また、本方式は分散型アイデンティティ（DID）とも考え方に近いものがあります。
しかしDIDが端末での仮想的な分散処理方式なのに対し、
本方式は端末に依存せず、カード2枚を使った物理的な分散処理方式を採用しています。
つまり、DIDの考え方をしつつも、カード2枚に情報を分割して認証を行うという
物理的な情報の断絶を構造に追加しているのです。
計算量をいくら増やしても空間の断絶をデジタルは突破することができません。
本システムの目的は、
本人性と権限を物理的に分離し、単一の端末に依存しない認証基盤を構築することです。
これにより、認証が成立する状態を保ちながら、柔軟かつ安全に運用できる仕組みを提供します。
この目的を実現することで、以下の三つの効果を同時に達成できます：
１、セキュリティを大幅に強化しつつ、認証をシンプルにする
２、紛失・故障・通信不能といった障害発生時にも、安全に使い続けられる運用を実現
３、既存のICカード機材を活かしながらセキュリティを底上げする
スマホの役割：
本方式は Card1 と Card2 の2枚のカードだけでも運用できますが、
スマホを補助デバイスとして使うことで、機能を強化することができます。
スマホはあくまで “管理のための窓口” であり、鍵の本体は Card1 / Card2 のカードにあります。
このため、スマホが故障しても認証は継続でき、
オフライン環境であってもカード２枚で認証が可能な構造になっています。
イメージ図
Card1（本人を証明・自動認証）
│
│ Bluetooth Low Energyなどで Card2 からの要求に対して自動承認
│
│ Card1 は、Card2 の署名がなければ通常運用では単体での使用はできない
▼
Card2（権限情報・契約情報・多階層での情報の管理）
│
│ 契約の条件・利用する権利などを保持
│ Card2 は、Card1 の署名がなければ通常運用では単体での使用はできない
│
│ NFC 等で読み取りが行われ、BLE 等で Card1 と通信し、
│ 承認をもって認証が成立する
▼
サービス利用開始
スマホ（補助デバイス）
├─ Card1/Card2の作成・管理
├─ 権限追加・変更・履歴表示
└─ 追加での認証や限定モードでのカードの再発行など
※ ユーザーが実際にやるのは Card2 を提示することだけです。
Card1 は提示不要で自動的に認証されますが、Card2 の承認がなければ
単体での使用はできない構造です。
※ 初期実装では BLE 等を用いるためバッテリー内蔵を想定するが、
将来的には省電力・非電源方式も検討可能
なぜ二枚カードにすると強くなるのか
1. 本人性 と 権限 を分離できる
今の世の中は「1枚のカード or 1台のスマホ」に全部詰め込みすぎています。
それだと 紛失した瞬間に全権利が消える or 流出する。
本方式では…
「あなたが本人であることの証明」 → Card1
「あなたは何ができるかの権利の証明」 → Card2
このように役割が完全に分かれるため、安全性が大幅に向上します。
昔は本人性と権限は一緒にしておいた方が安全でした。
２つを分離すると偽造され放題になるからです。
しかし今は逆で、２つを一緒にしておくと危険です。
同時に奪われると全てを失うことになるからです。
本人性と権限は銀行の通帳と印鑑の関係に近いものがあります。
現在はデジタル技術の進歩により、本人性と権限を安全に分離して
管理できるようになりました。
２つを一緒にしておくリスクはもう無くせるのです。
本人性と権限の性質について：
本人性は権限と繋がることにより、その性質を動的に変化させ、瞬間的に本人性ではなくなることにより、攻撃を受ける対象ではなくなる特性があります。
権限もまた、本人性と繋がり、かつ了承をうけることにより、存在を実行者へと変質させ権限ではなくなることで、攻撃を受けなくなる性質があります。
つまり本人性も権限も両方とも情報の相転移を起こす性質をもつのです。
水が氷ったり蒸気になったりするのと同じ仕組みです。
本システムは本来は１つとして扱われてきた、この性質をもつ２つの要素を分離して、
セキュリティに応用しています。
分離した２つの要素は安全に扱われ、１つだけでは何の力もありませんが、２つ合わさった時に初めて意味を持ちます。しかし、その性質により攻撃対象となることはありません。
つまり、どこにも攻撃される存在がいなくなる状態を作り出せるのです。
実際にやっていることは、とても単純です。
自然界の法則を使ってセキュリティを作っているようなものです。
※ 本文で用いている「相転移」とは情報が条件によって性質を変える状態変化を
比喩的に表したものです。
※ 以下は、本人性と権限を分離して設計した際に見えてきた、
情報構造そのものに関する考察です。
本人性と権限を物理的に隔離し扱うことにより新しい情報構造に繋がる現象が起こります。
この情報構造は本質が本人の存在証明つまり本人性という要素にあり、それに権限（拡張性）という要素を外部で組み合わせた時に新しい構造に変化する性質を持ちます。
この新しい情報構造は高い拡張性と共に攻撃を無効化する性質を持っており、
攻撃自体を成立させない状況を作ることが可能です。
本システムは後付けではありますが、そのセキュリティ特性を応用したものとなります。
本人性と権限の関係は、合意あるいは最小単位での認証に近い状態ではないかと思います。
本人性は権限との組み合わせにより、その性質が権限寄りに変化すると考えられます。
そうでなければ構造の説明がつきません。
本人性は情報構造において相転移を行いながらも同一性を保持する 安定基底 であり、
その性質は物理構造における電子に近いものがあると考えられます。
特に電子の回路が閉じて電流が流れる仕組みと同じように、情報が閉じると流れを維持
しつつ本人性を保つ構造が似ています。
この性質により本人性をコピーしても同じものを作ることが出来ない特性を持つと
思われます。
本人性・権限・認証の３つの関係は物理の電子・軌道・観測に近いものと考えられます。
この本人性を本質とした情報構造に組み合わさるのは 権限 の他には 認証 があることが
分かっています。例えば銀行などでは本人確認が必要になるわけですが、これを確認しに行く
動作が認証になります。本システムの場合だとこの認証の役目はカード２枚側ではなく
サーバ側などでの動作になるかと思います。
以下は情報構造をもっと知りたい方への入門編です。
https://zenn.dev/numa_mil/articles/29d684a5e6b4a4
2.カード2の権限の多層構造
Card2 は「単に権限を入れたカード」ではなく、
次のような動的に変化する権限を階層構造で入れられます。
入退室：（建物 → 階層 → フロア）
機器使用：（一般資格 → 上級資格 → 最上級資格）
端末へのログイン：（一般アカウント → 管理アカウント → 特権アカウント）
時間制限：（平日昼間のみ・夜間・休日など）
期間付き権限：（1週間限定のゲスト、1度限りの入退室・プロジェクト期間限定など）
役職ごとに付随する動的な権限
これらの権限をCard2に入れた上で、動的に変化させながら管理することが出来ます。
Card2の権限の使用や更新には常に Card1 の署名が必要なため権限が本物であることを
保証することができます。
個人利用のメリットも大きい
家の鍵、自家用車やカーシェアリングなどの車の鍵が簡単に登録でき、
それらの家族用の鍵の即時発行も可能
キャッシュカードやクレジットカード、保険証
スマホやPCのログインなどを安全に管理
オフライン環境であってもカード２枚で認証が可能になります。
※Card2は以下のような動的に変化する条件を多層構造に入れることができる。
スーパーの利用者：（Card2に権限が動的に更新される）
・ 入退店証明 入店 → 買い物中 → 退店
・ 精算証明 精算前 → 精算済み
・ 商品の割引 使用前 → 使用 → 使用後（商品名 条件：時間限定・個数限定など）
・ 駐車場 駐車開始 → 料金精算 → 駐車終了（条件：時間・購入金額で無料など）
・ コーヒー引換券 引き換え前 → 引き換え後（条件：時間限定・お代わり自由など）
情報構造としての本質は買い物を精算したかなどの行動記録ではなく、誰がいつそこに存在していたかを証明することにあり、それが情報の次なる進化の形であると考えています。
権限の本質は承認の証明にあります。権限は本来は静的なもののように思われますが、
実際には常に動的に変化しています。
それを文字などで静的に表現しているので動的に感じないのです。
権限は承認されるごとに動的に変化していきます（勤務＞休憩＞退社など）
権限自体はどのように変化してきたかの変化の履歴は持ちません。
現在の承認された権限を１つだけ表示するだけなのです。
この履歴が残らない性質も攻撃を受けない事に繋がっていきます。
権限が承認された変化の記録はサービスサーバに残ります。
権限は使用者本人の承認で変化するものですが、他者の持つカード１（本人性）の承認も受け入れる性質を持ちます。つまり使用者と他者の承認を組み合わせた上での権限の変化が可能なのです。
何人もの上司の承認の元で初めて成立する重複承認による権限の実行などが
可能になります。
権限とは表面上は１つの承認によってのみ成り立っているように見えますが、
実際には非常に多くの人の承認を集めた上での権限になっている場合が多いのです。
これは権限の性質が持つ自由度の高さを表すものですが、
それと同時にきちんとしたルールを設けておかなければいけない部分でもあると考えます。
セキュリティの考え方として：
全体のセキュリティを上げることにより、副次的なものとして利用者本人の行動のセキュリティレベルも上がってしまう現象が発生します。
それは利用者のセキュリティを守ると同時にその行動を記録するものであり、それは利用者の行動の安全性を担保するものともなる重要なものです。
この利用者の行動が記録されるという考え方はまだ先進的なものですが、現在の実際の取引においても裏側では既に同じことが行われています。
これはその流れを正常な進化の形であると判断し、それを表面化させると同時にその過程を
単純で明確にするものです。
3. Card2 は ICカード互換で既存設備が使える
企業、学校、交通機関など多くの場所にはすでに大量のICカードインフラが存在します。
Card2 はそれらICカードの設備と互換性を持たせることが可能です。
・各入退室用のゲート
・駅の改札
・銀行のATM
・会社の社員証リーダ
・学校内のカードリーダ
・研究設備の端末
これらの設備を買い替えずに、それまでのICカードを Card2 で使えるようにした上で、
低コストでセキュリティを劇的に底上げできます。
Card2 は、外部のリーダーには 古いICカード として振る舞いながら互換性を維持しつつ、
内部は最新認証を使用しています。
Card2 は提示すれば NFC などを使って Suica などと同じように認証されます。
Card2 は用途に合わせて形状や規格を自由に変更して Card1 の承認のもとで複数の
Card2 デバイスとして追加・運用が可能です。
※ 本方式は、NFC に対応した読み取り機材での利用を基本としています。
著しく古い機材での利用は、セキュリティを保証できないため使用不可と
させていただきます。
4. 紛失に極めて強い
Card2 を無くした場合：
Card2 権限本体は Card1 の署名が必要なので、ただのカードになる
card1 があればスマホやサーバの情報を元にcard2の即時再発行が可能
スマホや管理サーバで失効処理を行えば安全に無効化可能
Card1 が安全な場所にあるため、大きな事故にはならない
Card1 を無くした場合：
Card1 は本人を証明する大事なカードだが、単独では権限が成立しない構造のため、
紛失時にも致命的な事故にはならず、本人確認を行うことで再発行・復旧が可能である。
スマホやサーバで無くした Card1 の自動認証を停止し完全に無効化する
スマホの生体認証・PINによる限定モードで本人確認とCard2を用いた上で Card1 再発行申請
Card2 を新しい Card1 でも使えるように更新する
Card2 には権限情報が残っているため、現場の作業やサービス利用はすぐに復旧可能
スマホを無くした場合：
認証の本体は Card1 / Card2 にあるため、権限や情報の流出は起きない
再ログインや失効処理はバックアップ端末や管理サーバから行える
→ 三つのデバイスが互いに補完・保険になり、安全性と運用性を両立する構造
紛失のイメージ図
Card1紛失：
├─ Card2単体だけでは使用できなくなる（署名承認できない）
├─ スマホや管理サーバを通じて、Card1の自動認証を停止し完全に無効化する
├─ スマホの限定モードで本人確認しCard2を用いて、Card1を再発行が可能
├─ Card2を新しいcard1で使えるように更新する
└─ 日常運用は停止するが、復旧可能
Card2紛失：
├─ Card1が存在する場合、Card2を無効化し新しいCard2発行可能
├─ 日常権限は新しいCard2で回復
└─ セキュリティは保持される
スマホ紛失：
├─ Card1 / Card2は通常通り使用可能
├─ 権限の変更や追加、再発行は不可（スマホがないため）
└─ 日常運用は影響なし
三つのデバイスの役割
Card1：本人性の根源カード
本人を識別するための鍵を保持するカード
これが「あなた本人である」という証明
Card1 は Bluetooth Low Energy などで自動認証されるカードのため、
ポケットの財布などに入れたままで利用でき、面倒な取り出しは必要ありません。
Card1 / Card2 のカード2枚の組み合わせで認証を行います。
しかし、使用者が実際に行うことは今までと同じように
カード（card2）を1枚提示するだけです。
Card1 は自動認証されることで、カードの提示をしなくて済む構造です。
Card1 は、自動で本人確認が必要なサービスなどに使用可能ですが、
認証や操作を行うには必ず Card2 の承認が裏側で必要です。
Card1 は自動で認証処理を行い、ゲートなどの全自動での通過にも使用できます。
ただし、この全自動認証が有効になるのは、Card2 の承認が必要です。
Card2 の作成・更新・権限付与・使用は、すべて Card1 の自動での承認が必要になります。
初期においてはバッテリーを内蔵する必要があります。
全自動で認証されることで手を離せない仕事などでの認証にも使えます。
紛失時はスマホの限定モード（生体認証・PIN）で本人確認手段を用いて再発行手続きが可能です
位置付け：
認証構造の基点となるカードであり、Card2 を含む他カードの正当性を担保する役割を持つ。
補足：
※ Card1 には本人の証明と登録番号は含まれますが、氏名などの個人情報は保持していません。そのため、Card1 を紛失しても個人が特定されることはなく、安全に使用できます。
ただし Card1 を作成時には本人確認が必要で、その記録は発行システム側に保持されます。
この仕組みにより、Card1 は本人であることを証明するカードとなります。
※ Card1 には発行サーバに登録された基本番号と、Card2 との間で使用するオリジナル番号、そしてサービス登録用に派生した番号の3種類があります。派生番号は各サービスごとに
生成され、登録するサービスのサーバ側で管理されます。オリジナル番号は Card1 と
Card2 の間でのみ使用され、サービス用のサーバには登録されません。
※ Card1 は BLE などによる自動認証を前提とするため、信号が一定時間検知できなくなった
場合にスマホが警告を出すなどの紛失・置き忘れ検知やバッテリー切れを通知する仕組みを組み込む余地があり、同様の仕組みはスマホ側の置き忘れでもカードが音を出すなどで応用できる
可能性があります。
※ なお、電池残量低下やトラブル時の補助手段としてNFC による限定的な認証・管理操作に
対応することも想定しています。
※ また、Card1 と Card2 は少し離して運用することで安全性が高まる構造であるため、
両者が長時間近接している状態を検知し、スマホやカード側で注意を行う仕組みを組み込む
余地もあります。
※ バッテリーが切れている場合でも、NFC による手動提示モードでの認証が可能です。
この場合リーダー側で一時的に状態を保持し、2枚のカードが確認できた時点で認証を成立させます。
※ 通信環境や混雑状況により自動認証が成立しない状況では、Card1 と Card2 を明示的に提示する手動モードへ移行する。このモードでは利用者の意思と物理的所持が明確になるため、自動認証時よりもさらに高いセキュリティレベルが確保される。
※ 本方式では、BLEは利便性向上のための補助的通信手段として位置付けており、
電波干渉・妨害・混雑などによりBLE通信が成立しない場合でも、
NFC等の近接・明示的操作によって認証を継続可能な構造としている。
Card2：権限をまとめるカード（ICカード互換）
入退室権限、端末ログイン権限、家の鍵、車の鍵、キャッシュカード、クレジットカードなど様々な権限を多階層的に保持できます。
必要に応じて、別の形状・形式の Card2 を作成することも可能です。
役職権限なども Card2 に保持することで、専用ゲート通過時などで全自動での認証が行える構造となっています。（混雑する状況ではNFCで Card2 を提示する事もあり得ます）
この全自動認証には Card1 / Card2 両方の承認が必要です。
また、ゲートを全自動で通過するのに時間制限や回数制限などの条件を追加することも
可能です。
通常はBLEによる全自動認証でゲート通過が可能ですが、駅の改札などでの混雑時にはNFCでの認証に自動で切り替えることも可能です。
FeliCa・交通系ICカード等と互換のある規格であり、既存のリーダーの多くで
使用することが可能になる
Card1 によって承認・署名されないと Card2 だけでは使えないため、改ざんしにくい
Card2 は権限データを署名付きで保持するだけで、実際の鍵素材は Card1 が担保する構造。
Card1 は提示せず自動認識させ普段は Card2 を使用する（入室・機器使用・端末の認証など）
Card2 は NFC による提示・読み取りを基本とますが、Card1 との相互承認や権限処理を
行う場合には、小型バッテリーを用いた BLE 通信などを利用します。
Card2 は提示すれば NFC などを使って Suica などと同じように認証される
本方式は、NFC に対応した読み取り機材での利用を基本としています。
著しく古い機材での利用は、セキュリティを保証できないため使用不可と
させていただきます。
Card2 の権限はスマホやサーバを介して個人が権限を変更できるものと、組織の管理者によってのみ書き換えられるものなどとに分かれる。OSにアプリを入れるような感じに扱える
盗まれても Card2 単体だけでは認証にならないので安全
→ Card1＋スマホ側の管理で強力にガードされつつ使用することが可能になる
位置付け：
“何ができるかの権限を保持するカード”。普段使うカード。
補足：
※ 全自動でのゲート通過を行う場合は、ゲート側の機材が NFC/BLE 通信や自動開閉に対応
している必要があります。
また、混雑している時や多数のカードが同時に近接している環境でBLEが正確に動作しない
可能性があり、NFCでの Card2 の提示が必要になる場合があり得ます。
事前にゲートがBLEの数が多くなったと自動で判断し NFC に切り替える仕組みもあり得る
のではないかと考えます。
※ また、NFCでゲートを通過する場合、混雑時にはカード同士がBLEで承認要求を瞬間的に何度もやり取りする仕組みが必要になるかもしれません。
この際カード2は自律的に信号を増やすか
ゲートからの指示に応じてBLEのやり取りの回数を調整することも可能です。
これにより古いゲートでも、混雑時でもスムーズに承認を行った上で
通過できると考えます。
※ 混雑が発生しやすい主要改札は比較的新しい設備が導入されていることが多く、
本方式ではそのような環境ではNFCを併用したBLEの制御付き認証を使い。
比較的空いている場合にはBLEによる全自動認証を用いる運用を想定しています。
※ Card2は指紋による生体認証機能を備える余地があり、
必要とされる時には指紋での認証を追加できる可能性があります。
※ Card2もBLEに対応しているため、Card1と同様に置き忘れ検知やバッテリー切れの通知に
対応できる余地があります。
※ Card2に電子ペーパー画面を追加し、Card1やパスキーなどによりセキュリティが保証された上
でバーコードやパスワードなどの表示が可能になるかもしれません。
イメージ図
Card1（本人を証明）
│
│ Card2 への自動認証・権限発行
▼
Card2（権限カード・IC互換）
└── Card1 の署名がなければ単体では使用不能
スマホ：補助デバイス
Card1 / Card2 の管理、権限の確認、追加、変更、履歴の表示などを行う
Card1 / Card2 の使用で不十分とされる場合の追加での認証（生体認証、PIN）の役割
基本的には Card1 / Card2 の組み合わせでの認証での補助的な認証デバイス
スマホが無い場合でも Card1 / Card2 だけで認証は可能
Card1 が無くても、限定モードで Card1 の再発行申請が可能で Card2 も同様に可能
スマホ単体では強い権限は行使できない（鍵そのものは入れない）
操作用の「窓口」
位置付け：
“操作するデバイス”。鍵の本体は持たない。
この方式のどこが新しいのか（まとめ）
認証の本質を三つに分割（本人性・権限・操作）
しかも 低コストで現実社会に即導入できる構造
Card2 を ICカード互換にすることで社会実装を簡易化
Card1 が最上位鍵なのに「普段取り出さずに自動認証」という設計
スマホ依存ではなく、あくまで補助として使う
紛失や故障に対して極端に強い
これは「既存のICインフラを活かしながら、認証を進化させる」シンプルで強力な方法です。
パスキーを扱うイメージ図（例）
サービス
│ パスキーの登録を要求
▼
スマホ（操作・確認）
│ ユーザーのUI操作
│ 生体認証 / PIN
│ Card2をスマホにかざす
▼
Card2（パスキー保持・権限カード）
│
│ パスキーの使用を要求
│ （Card1の署名も必要なので要求）
▼
Card1（本人を証明・自動認証）
│
│ 本人性の自動承認・署名
│ パスキーの使用可否を承認・署名
▼
Card2（署名付きパスキー応答）
│ パスキーのCard2への書き込み
│ 使用条件なども書き込む
▼
パスキーのサービスの認証成立・使用開始
スマホ（補助デバイス）
└─ パスキーの追加・削除・整理
※ ユーザーが実際にやるのはCard2を提示することだけです。
Card1 は提示不要で自動認証され、スマホは登録・管理時のみ使用されます。
※ パスキーのCard2への書き込みは登録・更新時のみ
※ デバイス依存というパスキーの弱点を物理的なカード2枚で補うことで、
セキュリティも底上げし、パスキーをさらに強靭なものにする感じです。
カーシェア・レンタカーの契約（例）
スマホ／車載ナビ
│ 利用登録開始
▼
Card1（本人を証明・車両への近接・自動承認）
│ 承認成立
▼
Card2（提示）
・免許証情報の確認
・利用契約の成立
・車両の鍵／有効時間などのCard2への書き込み
│
▼
車両利用開始
※ Card2 は Card1 の承認が成立した場合のみ有効化される
※ 車両は、契約条件の有効性とCard1が近接して存在する状態を確認し、利用可否を判断する。
ゲート通過時のイメージ図（例）
※ 通常はゲートがBLEで全自動で通過でき、混雑時にはNFCでのカード提示に切り替えた場合
通常時にBLEでゲートを全自動で通過する場合
│ BLE でCard1に本人証明と通過する資格の証明を要求
▼
Card1（本人を証明）
│ BLE で Card2 に自動承認信号送信
│ BLE で Card2 に通過する資格の証明を要求
▼
Card2（権限・役職情報カード）
│ Card1 から自動承認を受け取る
│ Card1 からゲートを通過する資格の証明の要求を受け取る
│ Card1 へゲートを通過する資格の証明を送信
▼
Card1（承認信号を受け取りゲートへ返送）
│ ゲート へ本人である証明を送信
│ Card2 から受け取った通過する資格の証明をゲートに送信
▼
ゲート（自動開閉）
│ Card1 から本人である証明を受け取る
│ Card1 からゲートを通過する資格の証明を受け取る
│ ゲートの通過の承認/不承認を決定する
│
│ 時間制限・回数制限などの条件が適用可能
▼
ゲートの通行を許可/不許可を決定する
駅の改札の混雑時にNFCでゲートを通過する場合（カードの提示が必要）
│
▼
Card2（権限・役職情報カード）
│ NFC で手動で提示して ゲート に通過の要求を送信
│ ※ NFC を使用したことによりBLEの信号を多く出すブーストモードに自動で変更
│ ※ 古いゲートではCard2がBLEのブーストモードになるこで信号を増やして対応可能
│ ※ 新型のゲートの場合は混雑時に信号をどれくらい出すかの指示が出るので合わせる
▼
ゲート(NFC）
│ Card2 へ本人証明を要求
│ Card2 へゲートを通過する資格の証明を要求
│ 混雑時にはcard2へ信号を瞬間的に多く出すように指示を出す
▼
Card2（BLE）
│ Card1 へ本人である証明を要求
▼
Card1（BLE）
│ Card2 へ本人である証明を送信
▼
Card2（NFC）
│ ゲート へCard1から受け取った本人である証明を送信
│ ゲート へ通過する資格の証明を送信
▼
ゲート（自動開閉・NFC）
│ Card2 から本人である証明を受け取る
│ Card2 からゲートを通過する資格の証明を受け取る
│ ゲートの通過の承認/不承認を決定する
│
│ 時間制限・回数制限などの条件が適用可能
▼
ゲートの通行を許可/不許可を決定する
※ 全自動でのゲート通過を行う場合は、ゲート側の機材が NFC/BLE 通信や自動開閉に対応
している必要があります。
また、混雑している時や多数のカードが同時に近接している環境でBLEが正確に動作しない
可能性があり、NFCでの Card2 の提示が必要になる場合があり得ます。
事前にゲートがBLEの数が多くなったと自動で判断し NFC に切り替える仕組みもあり得る
のではないかと考えます。
※ また、NFCでゲートを通過する場合、混雑時にはカード同士がBLEで承認要求を瞬間的に何度も
やり取りする仕組みが必要になるかもしれません。この際カード2は自律的に信号を増やすか
ゲートからの指示に応じてBLEのやり取りの回数を調整することも可能です。
これにより古いゲートでも、混雑時でもスムーズに承認を行った上で通過できると考えます。
※ 混雑が発生しやすい主要改札は比較的新しい設備が導入されていることが多く、
本方式ではそのような環境ではNFCを併用したBLEの制御付き認証を使い。
比較的空いている場合にはBLEによる全自動認証を用いる運用を想定しています。
満員電車内の使用イメージ図（例）
※ 通常は混雑する満員電車の中ではスマホを見る程度ですが、もしCard2の認証が必要になった
場合を想定し、これを作成しました。
※ 満員電車など多数のBLE機器が存在する環境では、NFCを起点としてBLE Privacyを用いた
非接続・短時間の相互認証を行うことで、周囲に影響されず安全な本人確認を実現します。
満員電車内・サービス利用（例：改札・端末・スマホ補助）
利用者
│
▼
スマホ
│ Card2を NFC でスマホに提示する
▼
Card2（権限・操作カード）
│
│ ※ NFC で提示されたことにより「混雑環境」と判断
│ ※ BLE Privacy モードを有効化
│
│ ・BLEは非接続型アドバタイズのみ使用
│ ・一時的な匿名ID（RPA）を発信
│ ・ブーストはせず、短時間・限定通信
│
▼
（BLE Privacy 環境）
│
│ 周囲には多数のBLE信号が存在
│ → Card2のIDは第三者には識別不能
│
▼
Card1（本人性カード）
│
│ Card2と共有している鍵により
│ Card2のRPAを「自分宛」と認識
│
│ 暗号チャレンジを受信
│
▼
Card1（BLE）
│
│ 署名付きレスポンスを生成
│ （短時間有効・使い捨て）
│
▼
Card2（BLE）
│
│ Card1からの応答を受信
│ ※ 周囲からは意味不明なBLEパケット
│
▼
Card2（NFC）
│
│ NFC経由で
│ ・本人性の証明（Card1署名）
│ ・権限・契約情報
│ をリーダー／スマホへ送信
│
▼
リーダー / スマホ / ゲート
│
│ 本人性＋権限の確認
│ BLEは直接関与しない
│
▼
認証成立・処理続行
銀行のATMのイメージ図（例）
銀行ATMを利用する（カードの提示が必要）
│
▼
Card2（取引権限・金融操作カード）
│ NFCで手動で提示して ATM に取引開始の要求を送信
│ ※ NFCを使用したことによりBLEの信号は通常モードで行われる
▼
ATM（NFC）
│ Card2 へ本人である証明の要求
│ Card2 へ取引権限（口座・限度額・操作権限など）の証明を要求
▼
Card2（BLE）
│ Card1 へ本人である証明を要求
▼
Card1（BLE）
│ Card2 へ本人である証明を送信
│ （署名付き・短時間有効）
▼
Card2（NFC）
│ ATMへCard1から受け取った本人である証明を送信
│ ATMへ取引権限・条件（取引金額・操作可否など）を送信
▼
ATM（認証・取引制御）
│ Card2から本人である証明を受領
│ Card2から取引権限の証明を受領
│
│ 本人である確認と権限の両方を確認
│ 時間制限・回数制限・金額制限などの条件を適用
│
│ 高リスク操作のため PIN入力を要求
▼
利用者（PIN入力）
│
▼
ATM（最終確認）
│ PINの照合（回数制限・時間制限）
│
│ 時間制限・回数制限・金額制限などの条件を適用
▼
ATM
│ 許可／不許可を決定
▼
現金引き出し・入金・残高照会・その他取引を実行
PCなどへのログイン（例）
レベル1：通常ログイン（用途：私用PC・自宅・低リスク環境）
PCを利用する
│
▼
Card2（操作権限カード）
│ 手動で提示してPCへログイン要求
│ NFC / USB / 有線など
▼
PC（認証要求）
│ Card2へ本人確認の要求
▼
Card2（BLE）
│ Card1へ本人である証明を要求
▼
Card1（BLE）
│ Card2へ本人である証明を送信
│ （署名付き・短時間有効）
▼
Card2
│ PCへ本人である証明を送信
│ PCへ操作権限を送信
▼
PC（ログイン成立）
│
│ 登録されているCard1の近接を継続監視
│
▼
通常操作を許可
│
├ Card1が離れた場合 → 画面ロック
└ Card1が戻れば → 即復帰
レベル2：高セキュリティログイン（用途：業務・開発・社内端末）
PCを利用する（高セキュリティ）
│
▼
Card2（操作権限カード）
│ 手動で提示してPCへログイン要求
▼
PC（認証要求）
│ Card2へ本人確認と権限確認を要求
▼
Card2（BLE）
│ Card1へ本人である証明を要求
▼
Card1（BLE）
│ Card2へ本人である証明を送信
▼
Card2
│ PCへ本人証明＋権限を送信
▼
PC（一次認証完了）
│
│ 高リスク操作のためPIN入力を要求
▼
利用者（PIN入力）
│
▼
PC（最終認証）
│
│ 登録されているCard1の常時近接を監視
│
▼
操作を許可
│
├ Card1が離れた場合 → 即ログアウト
└ 再利用時は再認証が必要
レベル3：拘束モード（用途：金融操作・管理端末・不正防止・事故防止用途）
PCを利用する（拘束モード）
│
▼
Card2（重要操作カード）
│ 手動で提示してPCへログイン要求
▼
PC（厳格認証要求）
│ Card2へ本人確認・権限確認を要求
▼
Card2（BLE）
│ Card1へ本人である証明を要求
▼
Card1（BLE）
│ Card2へ本人である証明を送信
▼
Card2
│ PCへ本人証明＋権限を送信
▼
PC（一次認証）
│
│ PIN入力を要求
▼
利用者（PIN入力）
│
▼
PC（拘束モード開始）
│
│ Card1・Card2 両方の近接を常時監視
│
▼
操作を許可（制限付き）
│
├ Card1またはCard2が離れた瞬間
│ → 即ログアウト
│ → セッション破棄
│ → ログ記録
└ 再開には最初から再認証
古いICカードをCard2（互換）で使う場合（例）
古いICカードをCard2へ登録する場合 ：
利用者
│
▼
スマホ（管理アプリ）
│
│ 古いカード登録を選択
│
▼
スマホ ←── NFC ── 古いカード
│
│ ・カード種別判別（キャッシュカード / IC / クレカ等）
│ ・互換モード判定
│ ・読み取り可能な範囲のみ取得
│
▼
スマホ
│
│ Card1 に本人性の確認を要求
│
▼
Card1（本人性カード）
│
│ 本人確認・署名（初回登録用）
│
▼
スマホ
│
│ 古いカード情報を
│ 「直接使えない形」に変換
│ （鍵化・トークン化・ロック）
│
▼
Card2（権限・操作カード）
│
│ ・古いカード由来の情報を格納
│ ・Card1 の承認がなければ無効
│ ・単体では使用不可
│
▼
登録完了
古いICカードを登録したCard2を実際に使う場合 ：
サービス端末（ATM / 改札 / リーダー）
│
▼
Card2 を NFC で提示
│
▼
Card2
│
│ 古いカード由来の権限を使う準備
│ Card1 に本人性確認を要求（BLE）
│
▼
Card1（BLE）
│
│ 本人性を証明（短時間署名）
│
▼
Card2
│
│ ・ロック解除
│ ・互換モードで情報を生成
│
▼
サービス端末
│
│ 従来カードと同等の処理
│ （中身は違うが振る舞いは同じ）
│
▼
取引成立
混雑・通信不安定時（手動モード）
利用者
│
▼
Card2 を NFC で提示
│
▼
サービス端末
│
│ 本人確認を要求
│
▼
Card1 + Card2
│
│ 両方を明示的に提示
│
│ ・物理所持
│ ・利用意思
│ が明確になる
│
▼
サービス端末
│
│ 高信頼モードで認証
│
▼
取引成立（より高セキュリティ）
最後に
このフレームワークは、「2枚のカード」を標準的な構成として提案していますが、セキュリティ要件や運用の都合に応じて、カードの枚数は1枚に減らしたり、3枚以上に増やしたりすることも可能です。また、カードの形式や形状も柔軟に変更できます。重要なのは、枚数や形ではなく、「知っていること（知識）」「持っているもの（所有）」「本人であること（生体）」といった異なる認証要素を組み合わせるという設計思想にあります。これにより、特定の環境に合わせた柔軟なシステム構築が可能です。
※本記事は継続的に更新される設計メモである。
※この記事はZENNにも同内容を掲載しています。