908
回編集
差分
ナビゲーションに移動
検索に移動
41行目:
41行目: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
→第4回(R3-01-29)
*スマートフォンに認証器を搭載する場合の技術要件等も含めて、諸外国の例も参考とし ながら、整理をしていくことが必要。
*スマートフォンに認証器を搭載する場合の技術要件等も含めて、諸外国の例も参考とし ながら、整理をしていくことが必要。
*マイナポータルをはじめ、政府のウェブサイトのユーザビリティを改善すべきと、総理 等から強く求められているところであり、来年前半の早い時期に向けて整理が必要。
*マイナポータルをはじめ、政府のウェブサイトのユーザビリティを改善すべきと、総理 等から強く求められているところであり、来年前半の早い時期に向けて整理が必要。
==第3回(R2-12-23)==
https://www.soumu.go.jp/main_content/000730112.pdf
*資料全体に渡って、電子証明書と表記されている場合は秘密鍵を含んでおらず、電子証 明書等と表記されている場合は秘密鍵を含んでいるという理解でよいか。どこかで電子 証明書等を定義したうえで、電子証明書等と表記すれば十分な箇所が見受けられる。
*電子証明書は場合によっては他人にも見せるものであり、秘密鍵のような重大な秘密で はないことから、電子証明書と秘密鍵では相当に秘密の重大性が異なる。その辺りのメ リハリがあってもよいのではないかと思うが、秘密鍵と同様に管理して、削除もすると いう形でもよい。
*ネットワーク利用制限確認/SIM ロック解除等の大口対応窓口の設置、キャリアショッ プ店頭でのデータ消去対応については、現時点でキャリアが対応すべき理由には乏しい のではないか。また、MNO との間で中古端末の国内流通に向けた協議を加速することに 期待する声が高まっているとの記載について、これは本検討会のスコープ外と思われ、 別の場で議論されるべき事項と考える。
*自社が販売した Android 端末については、店頭で GP-SE 内のデータを消去可能と思われ るが、他社が関わったものなど全ての Android 端末の GP-SE 内のデータを消去できるわ けではないのではないか。また、実際に店頭では GP-SE 内のデータを消去するのみであ って、電子証明書が失効済であり適切に削除されていることの確認まではできないので はないか。さらに、端末の初期化では GP-SE 内のデータは消去できないのではないか。
*Google 社が定める Android 互換性定義ドキュメント(Compatibility Definition Document(CDD)において、生体情報については、ファクトリーリセットしたときにリ ムーブすることが規定されている。一方で、GP-SE については、Android 端末の実装必須要件ではないこともあり、GP-SE 内のデータ削除については規定がない。理想的には CDD の中で、GP-SE 内のデータについてもファクトリーリセットした際にはリムーブす ると規定いただき、メーカーにそれを準拠していただくのがよいのではないか。もし国 や地域によってはそれが必須要件となると困るという事情がある場合には、今回は日本 国内のスマートフォン市場において、FeliCa 対応のための要件の中で削除することを 規定するのが良いのではないか。
*今回の検討内容が実用化される時期において、既に GP-SE が搭載されたスマートフォン に対して、削除機能を後から具備できるか否かについて確認すべき。また、技術的に可 能であっても、実際にビジネスの観点からメーカーが後から削除機能を具備するか否か は疑問が残るので、それでも利用を推進するのか、削除機能が具備されることを必須要 件とするのか確認すべき。
*ガバナンスの効きづらいマーケットプレイスでの CtoC でのスマートフォン端末の売買 に対しての懸念やその対策について確認したい。
*GP-SE の状態を端末リセット等で初期化できてしまうこととすると、セキュアエレメン トそのもののセキュリティ、安全性の低下を招く可能性があるので十分注意しながら議 論することが必要。
*セキュアエレメントのデータを消去するソフトウェアの内容、品質は重要であり、ソフ トウェアそのものの認定の概念について検討すべき。
*エストニアのスマート ID 等を参考に GP-SE を必要としない方式の必要性も検討すると のことだが、こういったスマート ID 等は、リモート署名の仕組みを含んでいるように 思われるため、リモート署名についても記載したほう良いのではないか。また、利用者 証明用電子証明書が重要なデジタル ID であるという表現になっているが、一般的な表 現なのか確認してほしい。
*前回議論になった仮 PIN について、スマートフォンで PIN が全く設定されていない状態 で、最初に PIN を設定する際には TSM 側で仮 PIN を設定する必要があるということで理 解した。
*一時保留時に簡単な本人確認を行うとのことだが、署名用電子証明書が搭載されている スマートフォンを紛失し、それを悪意の第三者が拾得した場合、基本 4 情報、マイナン バー以外ほぼ全ての情報を拾得した者も持っていることとなるが、それは本人確認にな り得るのか。また、一時保留という措置自体の必要性を確認したい。
*移動端末設備用の電子証明書とカード用の電子証明書の扱いは同等なのかそれとも異な るのか確認したい。
*NIST SP 800-63-2 において議論されていた Level of Assurance(LOA)は、NIST SP 800-63-3 において Identity Assurance のレベル(IAL)、Authenticator Assurance の レベル(AAL)、Federation Assurance のレベル(FAL)の 3 つの体系に分解されてい る。カード用の電子証明書は対面での本人確認のため IAL3 であり、耐タンパ領域に格 納されているため AAL3 である。
*移動端末設備用の電子証明書について、マイナンバーカードが基となって derived され る環境を経て、プロセスが一定の IAL を保証できるならば、IAL3 と見なすことがで き、鍵の生成においても、秘密鍵は一切外へ出さないため AAL3 であることが保証できることから、対面での本人確認ではないもののカード用の電子証明書と同等と考えても 良いのではないか。
*EU でも同様にナショナル eID から発行された eID については最も高い保証レベルを認 めており、カード用の電子証明書と同等とみなしても良いと考えるが、ライフサイクル が異なるため識別は必要。また識別と区別の 2 つの表現が混在しているが、識別という 表現に統一すべき。
*署名して申請することとなっているが、15 歳未満の方は署名用電子証明書を持ってい ないため、15 歳以上の方のみを対象にするということで良いのか。
*国際標準の変化のスピードは早くなっており、スマートフォンのエコシステムにおける デファクトスタンダードとなっている CDD は毎年更新されていることから、毎年確認を していくことが重要。
*生体認証について、利用者証明用電子証明書への導入を提案し、署名用電子証明書への 導入については要継続検討と考えていたので、一旦このような整理で良いと思うが、将 来に向けての可能性に蓋はしないほうが良い。
*利用者証明用電子証明書におけるパスワードないし 4 桁の暗証番号、署名用電子証明書 におけるパスワード 6 文字から 16 文字に対して PIN という表現が利用者にとって分か りやすいか否か検討が必要。
*移動端末設備用の電子証明書とカード用の電子証明書の PIN は違うものであるべき又は 本人の判断で同じものを設定して良いといった考え方はあるのか。PIN を失念する方が 多数いる中、4 桁の方については、生体認証を利用できると道が開けるが、6 桁以上の 方については、またさらに別の PIN を設定するとなると、利用しやすいものになるのか 疑問であるため整理してほしい。
*サービスモデルを展開する中で、例えば健康保険証の活用といった一定の利用者を確保 できるものから、段階的に順次普及を図っていくという考え方も必要。今回のスマート フォン活用の取組は、最終的にはオンライン上で完結することを目指していると思われ るので、ユースケースの将来像の中にあるコンビニ交付については、過渡期としては良 いが、最終的には段階的に収束していく展開を考えるべき。
*エストニアについて、デジタル ID の普及率が 99%ということが取り上げられるが、ス マートフォン活用はあまり進んでいないのが実情で、35%程度しかオンラインでの手続 には利用されていないという話も聞いている。また、我が国が目指しているものと仕組 みに相当な差異があるところ、エストニアの 35%を超えるようなものを目指してほしい。
==第1次とりまとめ==
[[マイナンバーカードの機能のスマートフォン搭載等に関する検討会第1次とりまとめ]]
==第4回(R3-01-29)==
https://www.soumu.go.jp/main_content/000735971.pdf
*生体認証について、今回の電子証明書のスマートフォンへの搭載の場合にどのように活 用するのか確認したい。基本的には、ローカル PIN やパスワードで署名鍵が暗号化され ており、署名鍵を復号するための情報をスマートフォンに入れないと、電子署名ができ ないこととなる。GP-SE には、いわゆる署名鍵は平文で格納され、その利用の許可をす るために PIN 等の確認をしているのか。
*基本的な考え方として、ローカル PIN がスマートフォンから入力され、それを GP-SE に 渡し、GP-SE において誤りがないか確認をした後に署名するという手続きとなる。この スマートフォンからの結果に関しては、API を呼び出しその結果として、スマートフォ ンのレベルで一致したか否かの結果が渡ることとなるが、結果の渡し方については議論 の途上であると理解している。
*GP-SE、マイナンバーカードともに、署名鍵は外から取り出したり、覗いたりすること が一切できないチップ内の領域に平文の形で安全に格納される。カードはその中に入っ ている鍵をどのような状態であれば使えるかという管理機能を有しており、例えば PIN の場合だと、アプリケーションに PIN が入力され、内部の安全な領域に格納されている PIN 情報と照合すると、署名鍵を演算できる状態にするという制御を行っている。
*生体認証を活用する方向で検討することになっており、提案に示されている方法は有効 かと思われる。一方で、スマホ版の JPKI は、カード版の JPKI と異なり Android 上のア プリケーションと、GP-SE 内のアプリケーションをセットで考えなければならず、特殊 な実装になる。生体認証を実装するに当たって、それぞれのアプリケーション処理の J-LIS の責任分界について、今後検討が必要。
*提案に示されている問題が万が一発生した場合には、生体認証の機能を停止しつつも JPKI の PIN 入力は使える状態にして利用を継続できる考え方は、責任分界の観点から も非常に有効と思われる。
*Android の API において、生体認証で認証されたのか、PIN やパターンで認証されたの かは、アプリケーション開発者が知ることができるようになっている。Android の APIで使われたのか、ローカル PIN で使われたのかを基盤として知りうる手段をあらかじめ 設計、実装していくことが必要。
*公的個人認証法第 17 条において、CRL や OCSP を受けられるものが限定されている。住 民基本台帳カードのときは公的機関のみとなっており、マイナンバーカードになったと きに少し緩和されたのが今の状況ではあるが、過剰な規制のように思う。誰でも CRL や OCSP を受けられても良いのではないか。
*認証局の議論をしている中で ID 事業者という表現は誤解を招く恐れがある。認証業務 を営む事業者、電子署名法では特定認証業務、さらには認定認証業務という表現となっ ており、ID 事業者というのとはレイヤーが別であると認識している。
*エストニアの事例の eID、Mobile-ID、Smart-ID は、全て共通の eID が使えて、それを IC カードで利用する、SIM に格納してスマートフォンで利用する、簡便なポータルによ り利用するなど日本の考え方とは異なる。
*日本の場合は電子署名法と公的個人認証法それぞれ別々にあり、基本的に対象は同じ認 証局の世界であることから、まさに相互認証の概念になっていくと思われる。ID 連携 ということではなく、あくまでも X.509 証明書、認証局の連携の話の中で議論をしてい くべきであり、そこでどういった法律体系があるか整理をしていくことが必要。
*民間 ID といったときに、いわゆる民間署名検証者の議論と、電子署名法上の認証局の 発行した証明書の議論と、それらと紐付いた形で別のデジタル ID のようなものがある ときに、類型化とそれぞれの位置付けを明確にしていくことが必要。
*現状、JPKI の中でシリアル番号と証明書との紐付けを行っているが、シリアル番号は 連番であり、これまでいくつ証明書が発行されたかほぼ見ることができ、少し番号を変 えると他の方に当たる。シリアル番号はリスクが高いから保護しているという意識では あるが、本来、アイデンティファイアとして使うのであれば、よりエントロピーが高い ものを利用する方が望ましいが、歴史的経緯でシリアル番号による紐付けが広く行われ ている。民間でのユースケースが増えていく中で、本当にこの運用で良いのか。ID ご とに区別して扱えるような仕組みがあることが望ましい。
*日本の基準は NIST SP800-63-3 や eIDAS を踏まえながら検討されてきたものであるとは 思うが、現状の eIDAS と十分な相互運用性があるものとなっているかは疑問であり、 eIDAS と相互運用性のある基準にしていくことが必要。
*エストニアの事例の Smart-ID では、ID を入力して、デバイスに確認コードが表示さ れ、それを入力することとなっており、Mobile-ID では、SMS にいわゆるワンタイムパ スコードが送信され、それを入力することとなっている。最近の偽サイトや偽ブラウザ ではこのような仕組みを使って入力文字を搾取することがよく行われており、一見2要 素認証に見えるが実はそうなっておらず、今 NIST で議論になっているという認識。こ れは知識だけの1要素2段階認証であり、フィッシングに対しては脆弱である。
*電子証明書がスマートフォンに搭載されてより便利に利用できるようになることから、 パスワードではなくて、FIDO 認証を活用し、より広く多くの方々がメリットを享受で きるよう、フィッシングに対する課題を解決できるような利用方法を検討すべき。
*電子認証について、国が公共分野で民間 ID を受け入れるとなると、その民間 ID はどの 保証レベルに該当するのかを、何らかの形で認定・審査する仕組みが必要になるが、現 状のガイドラインとの整合等、もう少ししっかりした制度設計を行うことが必要。
*EU の場合、eIDAS が法律のようなものとして定義されており、eID などの電子認証がど の保証レベルに該当するかレギュレーションとして規定されている。それぞれの国が そのレギュレーションに合致しているかを評価して公表するという手順を行い、他国 の eID が自国で受けられるか審査する仕組みがある。日本においても、同様にいろい ろな側面から評価するような制度をつくるべき。
*リモート署名がクラウド型になり導入が容易となっているので、民間や行政手続きで の利用が進んでおり、日本でどの程度本格的に普及しているかを定量的に理解してお いたほうが良い。
*経済産業省の電子署名法研究会において、リモート署名について検討されており、EU においても同時期に検討を行っていたため、そちらも踏まえながら、JT2A においてリ モート署名のガイドラインを策定しているので、参考にしてほしい。
*エストニアの事例の Mobile-ID が有料とのことだが、今回の電子証明書のスマートフ ォンへの搭載に関しては、スマートフォンの買換え期間が今5年に1回となってお り、そのうち GP-SE 対応のスマートフォンでしか普及していかず、1人当たりのコス トがどの程度か不明であるため、どこまでのコストを許容できるのか分析した方が良 い。
*サービスに応じた適切な認証方法について示されているが、今後サービスを提供してい く中でそれぞれのサービスに応じてどの認証方法が良いのかというレベル分けも考えな がら検証いただき、結果をフィードバックしてほしい。
==第5回(R3-03-03)==
https://www.soumu.go.jp/main_content/000744289.pdf
*Option1 の場合、TSM 以外はエンドユーザーから見るとスマホ内の環境であり、それに 対して TSM は外部である。その通信は安全な SCP03 を使うとのことだが、ネットワーク 負荷や通信路での問題発生等、ネットワークを介するところについてどう評価するか。 Option2 の場合、スマホ内の話なので、非常にローカルな環境でできるように見える。 その時に、一般のアプリで簡単に GP-SE をさわれるようでは困る。ここにコネクタのよ うなものを間にかませて、そのセキュリティレベルをしっかり確保し、スマホアプリか らそのコネクタのような API をたたく構造にして、しっかりと GP-SE を守るという構造 も考えられる。
*不正なスマホアプリを想定したときに、安全性を見たら Option1 のほうが高いと思われ る。
*ネットワーク負荷がかからないという意味では、ローカル処理である Option2 のほうが 良いのではないかと思われる。
*セキュアエレメントの安全性のレベルと TEE の安全性のレベルは異なるというのが一般 的な考え方だと思うので、注意しながら進めていただきたい。
*Option1 と Option2 を考える上で、JPKIのアプレットの搭載や TSM からアプレットを搭 載するときの安全性等、総合的に評価していただきたい。
*TEE とセキュアエレメントの安全性のレベルに関してはヨーロッパも含め、国際的にど うレベル付けされているのか、また、現状マイナンバーカードで 4PIN を入力する局面 はそこまで機微ではないものも相当ある中で、どこまでこの方法でできるかしっかり議 論できると良い。
*資料3の観点4の利便性に関して、現状のマイナンバーカードとの比較において出てき ている論点だと思われるが、そもそも本来マイナンバーカードとしてできているべきだ けれどもできていないことは結構ある。スマホアプリで何を実現すべきなのかというこ とは、現状カードで実証していることに留まらず、もっと広範に見るべき。今のマイナ ンバーカードをただスマホに入れただけでは十分な利便性とは言えないのではないか。
*イギリスで導入された GOV.UK Verify の見直しの報告書を見ると、当初のもくろみに反 して銀行の口座開設やソーシャルメディアの身元確認の eKYC として使われていない。 これらの eKYC として使われるための要件とは何かを念頭に検証していくべきであり銀 行やソーシャルメディアの業界に意見を聞いたり、検証に参加してもらうことが必要で はないか。
*まずは住民票の添付等、マイナンバーカードの機能を搭載したスマホで役所に行かずと も手続ができるといった部分から始めるべきではないか。一番住民目線から、生活に密 着した形で活用した方が良い。
*資料3について、大量に利用するようになった際の性能面も検証しておいていただきた い。
*技術検証の在り方として、スマホで JPKI を利用する際というのは、GP-SE も含めてス マホの所有権は利用者側にあるため、TEE や生体認証の部分を含めて、J-LIS が安全性 を確認できる範囲に限界があることが想定されている中で、規約を定めて利用者と事前 に合意した上で使ってもらうことが必要になるのではないか。JPKI についてもどこま で J-LIS 側の責任として、どこからを利用者側の責任にするのかを、技術検証の際にも 確認しながら進めていただきたい。
*安全性が担保できている、あるいは運用に耐え得る安全性があらゆる面で確保されてい るかをどのような第三者に評価いただくかは難しいところである。その領域に熟知して いる方にきちんと俯瞰して評価いただき問題がないことを確認できるところまで検証で きると良い。
*電子署名法の認定と公的個人認証法の5号認定の比較等をしているが、この2つの制度 が同じような基準で同じようなことをやっているのに併存しているため、この2つをま とめていく方向で進めるべきではないか。
*電子認証と電子署名は分けて議論しなければいけない。
*我が国では公的個人認証は少なくとも X.509 で動いているため、これをどのように連携 していくか。今後、民間の認証局との連携ひいてはそれを使った ID の連携にはつなが る。そういう考え方で整理していく必要がある。
==名簿==
==名簿==