Identification・Authenticity・Authentication・真正性

「弁護士ドットコム」さんで、14日に「社会のデジタル化と法律実務」というのを話すので、スライドを作りながら、いろいろと考えていたところ、特に、トラストまわりでも使う真正性・Identification・Authenticity・Authenticationあたりの用語が、混乱しかけているので、自分のためにメモしようかと思っています。

まずは、上の図の左側。アナログ的な行為ですね。紙があって、思想主体たる本人が、その紙に記載されている文書を自己の思想であると「認証」して、その「名義」でもって、署名(または、押印)します。そして、その紙が、そのまま、裁判所の前に呈示されるわけで、単純明快(?)。

右側のデジタル社会になると、いろいろいな話がでてきます。会社の場合をさて置いても、思想主体って、誰なんでしょうか。そのあと作成されるドキュメントの名義人なのでしょうか。それともプログラムの作動者か。

次にドキュメントの受領者からみたとき、そのドキュメントが、誰からのデータであるか、というのを確認する行為というのは、どういう意味をもつのでしょうか。ドキュメントが、誰の思想であるかを識別(identificate)した上で、その表示された思想が、正確に作成された上に、受領にいたるまでに同一であるということが明らかになるということなのかなと思います。

この場合、思想が誰のものかというのを確認するには、識別子を提供してもらって((identification)確認することになるのでしょう。その作成のチェーンをみていった上で、正確に作成されて、同一であることが認証される(Authentication)ものとなるのでしょう。この場合に、この確認する行為やルールが認証(Authorisation)ですね。

(なお、identificationについては、こちらのブログが勉強になりました)

法的に真正性(Authenticity)と呼ばれているものをみていきましょう。

我が国でいけば、民事訴訟法第228条1項

文書は、その成立が真正であることを証明しなければならない。

とされています。そして、228条4項においては、

私文書は、本人又はその代理人の署名又は押印があるときは、真正に成立したものと推定する。

とされています。

米国であれば、連邦証拠規則901条(a)です。同条は、

 証拠のアイテムを認証(authenticating)し、または、識別する(identifying)要件を満たすには、提案者(proponent)は、問題となっている(コンピュータ記録あるいはその他の証拠)がその申請者が要求しているものであるということを認定することを基礎づけるのに十分な証拠を示さなければならない。

と定めています。これについて、司法省の捜索差押ガイドラインは、真正性という名称で呼んでいます。

この真正性について、同ガイドラインは、3つの問題があることを分析しています

第1に、当事者は、当該記録が作成されたのちに改変され、操作されあるいは毀損されたどうかを問題とすることによって、コンピュータの生成した記録とコンピュータに蔵置された記録の両方の真正性について異議を申し立てることができる。

第2に、当事者は、当該記録を生成したコンピュータプログラムの信頼性を問題にすることによって、コンピュータの生成した記録の真正性を問題にすることができる。

第3に、当事者は、その作成者の同一性を問題にすることによって、コンピュータに蔵置された記録の真正性に異議を申し立てることができる。

これらをひとつの図にあわせることができるか、ということになります。

これは、上のガイドラインの3つの段階があること、それについて、法的に、真正性を明らかにすること(認証-authentication)がいろいろな証明を助ける仕組みを準備していることを示しています。

あと、ここの関係で把握しておくべき概念は、eIDASに関していわれているセキュリティ性質としてのデータのオリジンの認証でしょうか。「秘密鍵の保有者のみが、対応する公開鍵でサインされたデータのオリジンのポイントとなりうるから、サインされたデータのオリジンの証明となる。」という表現になっていて、この作用が、データのオリジン認証(authentication)といわれています(例えば、Security guidelines on the appropriate use of qualified electronic signaturesなどの表現 例 3.2Security properties )

ということで、メモを作っても、なかなか整理されないのですが、

(1)真正性という用語は、成立に関する部分と、内容に関する部分とをともにいっている。

(2)成立に関する部分は、連邦証拠規則だと、識別といわれているようである。

(3)真正性を明らかにする行為が認証と呼ばれている。

あたりをメモしておくことにします

 

 

トラストワークショップ参加ありがとうございます。

トラストサービスの調査ワークショップ無事成功のうちに終了いたしました。

参加いただきましたみなさま本当にありがとうございます。

トラストサービスWGの開催が、新聞報道等でなされるなか、非常にタイムリーな企画となり、熱心な議論がなされたのは、非常に有意義であったかと思います。

トラストサービスWGの報道としては、

日経新聞「電子書類に公的認証-改ざん防ぎ信用担保 国際商取引を円滑化」

読売新聞「電子書類に公的認証・・・総務省会議」

ブログとしては、「”総務省が画策する「日本版eIDAS」は電子契約普及の追い風となるか」ですね

当社としても、3月末にむけての報告書完成にむけてさらに努力する所存です。

 

トラストサービスの調査ワークショップ 2019のプログラム

トラストサービスの調査ワークショップ 2019が、変更になりました。

変更後のプログラムは、こちらです。

13:30  開会
13:30~13:35 総務省挨拶 (調整中)
13:35~14:00 eIDASの現状
駒澤綜合法律事務所 辯護士/株式会社ITリサーチ・アート 代表取締役 高橋 郁夫
14:00~14:25 欧州の法規制
ポリシー・リサーチ・ユニット(総務省情報通信政策研究所特別研究員) 佐々木 勉
14:25~14:50 EUの技術標準
セコム株式会社 IS研究所 コミュニケーションプラットフォームディビジョン マネージャー 松本 泰
14:50~15:00 休憩
15:00~15:25 トラストサービス推進フォーラムの取組
セイコーソリューションズ株式会社 DXソリューション統括部 部長 柴田 孝一
15:25~15:50 日・EUのトラストサービスに関する制度比較
セコムトラストシステムズ株式会社 プロフェッショナルサポート1部 担当部長 西山 晃
15:50~16:00 休憩
16:00~17:00 パネルディスカッション
高橋 佐々木 松本 柴田 西山
17:00 閉会
です

トラストサービス推進フォーラムの活動の紹介等もさせていただき、さらに、多角的な観点から、我が国における今後のトラストサービスのあり方を考える機会にいたしたいと思います。

皆様 よろしくお願いします。

トラストサービスフォーラムinベルリン Day2 その3

最後のセッションです。

最初は、Dimitris Zacharopoulosさんの「CA/ブラウザフォーラム(CA/Browser Forum-Status and future activities)です。スライドはこちら

CA/ブラウザフォーラムというのは、規制団体ではなく、また、監督機関でもありません。むしろ、世界的な「標準機関」に近いものといえるでしょう。SSL/TLS証明書の提供/発行/ガバナンスについての相互のポリシ、実務をともに定めています

ブラウザは、トラストサービスプロバイダを「ルートプログラム」を通じて、そのssl/TLSトラストサービスを「監督」しています。
フォーラムは、ガバナンスの変更によって、フォーラムがサーバー証明書ワーキンググループとなりました。また、サブコミッティ、証明書発行者、証明書利用者へと名称の変更がありました。

また、他の話題としては、監査が、ETSIの標準とWebTrustの基準が、収斂しつつあります。

効果的な監督というのも重要な問題です。現在は、適合性評価機関となっています。が、誤った証明書は、適合性評価機関によって発見されるものではないのです。監督機関は、スキームをテストするにすぎないのです。
その意味で、関係当事者は、証明書「製品」によって十分に保護されているのか、トラストをおいているのか、という問題があるのです。
また、現状でのSSL/TLSが、十分なのか、監査報告書での不適合部分が小規模とされること、適格タイムスタンプは、RFC3161のタイムスタンプではないこと、などの問題があるとされています。

次は、Andreas Philippさんの「ハイブリッドPKI/IoTのソリューション」(Hybrid PKI: Solution for IoT)です。スライドは、こちら

IoTセキュリティの重要性は増しており、また、PKIは、IoTにおいても事実上の標準になっているとされます。
IoTは、多様性を有しており、フリーサイズの解決策は存在しないこと、そこで、PKIに注目することになります。同社の対応としては、世界的な配置、負荷のピーク、OTについてのPKIソリューションなどがあります。
工場での動作を考えてみましょう。
イメージのスライドは、こんな感じです(スライド14から)

クライアントのオンサイトでの処理があり、工場での処理もされ、それも認証局、登録局、サーバーのアプライアンスが発展することになります。工場ともなれば、誤作動の場合の安全性の問題は到底看過できません。
まさに、PKIも組み合わせたハイブリッドで、動かしてみましょうということになるのかと思います。

最後は、Andrea Valleさんの「アドビとクラウド署名コンソーシアム」(Adobe and the Cloud Signature Consortium)です。スライドは、こちら

クラウド署名コンソーシアムは、クラウド署名についての標準を構築しようというものです。

2016年に設立され、クラウドベースの電子信託サービスの促進、相互作用を容易にするために共通のアーキテクチャーとビルディングブロックを設計する、これらのやり取りを容易かつ相互運用可能にするためのプロトコルおよびAPIの技術仕様を作成、技術仕様をオープンスタンダードとして公開する、などのミッションを有しています。 (このようなプレスリリースもあります)
トラストサービスのための基準の開発のための貢献の相互交換を可能にするためにETSIとの協力協定を確立しており、具体的には、CSC API仕様は、ETSI TS 119 432「リモートデジタル署名作成のためのプロトコル」で参照されています。
また、CSC API V1仕様は、一般に公開されています。http://cloudsignatureconsortium.org/specifications

あとは、CSC技術仕様の簡単な説明、ロードマップ、アドビ署名がCSC の仕様に準拠していることなどの説明がありました。そのあと、実際のデモ、アドビ署名のロードマップについての説明もなされました。

トラストサービスフォーラムinベルリン Day2 その2 後半

第2セッションですが、一番興味深かったOlivier Delos ( Sealed)さんの「トラストリスト:何?-現在の状況、イニシアチブ、次のステップと課題」(Trusted Lists:
What’s up? Current situation & initiatives Next steps and challenges )です

eIDAS規則は、ピラミットをなしています。

この図は、適格トラストサービスに関して、EUトラストマークを頂点に、トラストマーク、監督体制、適格トラストサービスプロバイダ、適格トラストサービスに関する規定、それらを支えるベストプラクティス、標準がピラミッド構造をなしているのを物語っています。

トラストマークを直接にささえているのは、トラストリストです。

トラストリストは、適格トラストサービス(提供者)に対して、基本的な効果を有しています。
トラストリストの手続と様式は、共同体 実装決定(CID)2015/1505によって特定されています。この実装決定は、サービス指令によって、設立されたトラストリストとの継続性を確保し、適格事業者の法的確実性をたしかにするものです。また、適格電子署名・適格電子シールの有効性確認をすることで、クロスボーダーの認証を促進しようとするものです。

トラストリストは、加盟国が自動処理に適するようになさなければならない/適格事業者の情報を含まなければならない(強制的)、可読的な形で提供する/適格ではない事業者の情報を含むことができる(任意的)という双方の性格を有します。

上記実装決定(CID)2015/1505は、ETSIのTS 119 612 v2.1.1に基づいています。構成としては、トラストリストスキームおよび運営者、EC LOTL(トラストリストのリスト)へのリンク、適格事業者・適格事業のリストから成り立っています。

共同体トラストリストのリストは、加盟国のトラストリストの情報を含んだXMLのファイルであって署名/シールがされています。詳細な情報は、EUの公式がジャーナルで公表されています。ピボットリストのリストがあり、機械可読な証明の変更であって、その特別なインスタンスということになります。

また、EUトラストマークは、クリックすることによって、トラストリストをみる(Trusted List Browser)ことができます。
TLSO(Trusted List Scheme Operator)コミュニティがあります。そこでは、トラストリスト管理ツール、同ブラウサ、加盟国からの通知、サービスデスクなどが提供されています。

これをみることで、各国においてどのような適格トラストプロバイダーが、どう登録されているかがわかります。登録されている数をみてみると以下のようになります。

適格事業者数は、以下のとおり。

適格電子署名認証事業者

適格電子シール認証事業者

適格ウエブサイト認証事業者

事業者数

143

83

35

国数

27

22国

16国

増減事業者

-8

81

35

国数

-2

20

16

 

適格電子署名検証事業者

適格電子シール検証事業者

事業者数

9

9

国数

8

8

増減事業者

7

7

国数

6

6

 

適格タイムスタンプ事業者

適格電子配達内容証明事業者

事業者数

85

5

国数

21

4

増減事業者

63

3

国数

14

3

 なお、増減といっているのは、eIDAS実施6月後の時点での事業者数との相違の数です。

EUの範囲を越えて、相互認証をなすということが問題になります(eIDAS規則14条)。

この点では、法・監督・技術の三つの柱の観点から、マッピングを実現していかなければなりません。

ENISAでは、「監査の世界的承認」という文書を提供しています (という話ですが、見つかりませんでした)。
ETSIのSTF560(ESI 560 Standards for machine-processable signature policy formats and the global acceptance of European Trust Services)も参照する必要があります。
次のチャレンジとしては、意識と教育で、卓越を目指して、道を舗装していくことになります。

Dean Coclin ( Digicert)は、「SSLの産業傾向」です。スライドは、こちら

プレゼンは、いろいろいな交通標識の話で始まります。これに比較して、SSLのグリーンやグレイのサインは、わかりやすいでしょうか。

お札は、また、すかしがはいっています。EV証明書のセキュリティも同様です。

EV証明書は、偽造防止であり、適格ウエブサイト証明書は、EVに頼っています。アイデンティティが重要であれば、何が、EVを改善するのでしょうか。

また、ブラウザの設定によりhttpsへの移行が劇的な増加をみせています。(クロームだと78%以上、アンドロイドでも68%以上です) Chrome69からは、安全の文字がなくなっています。

アップルのsafariの表示も変わってきていますし、また、EVの市場も増加しています。

証明書のタイプでいうと、DV(ドメイン証明書)が94.3%、OV(企業証明書)が、5%、EVは、0.7%です。しかしながら、トラフィックだと状況が変わります。きわめて印象的です。

ちなみに3種については、こちらをどうぞ。

 

 

 

 

トラストサービスフォーラムinベルリン Day2 その2 前半

Day2の2コマ目のセッションです。

最初は、Michael Taborさんの「PSD2は、eIDAS適格証明書を金融サービスに導入する」(PSD2 introduces eIDAS qualified certificates to financial services)というプレゼンです。スライドは、こちら

決済サービス指令2は、このフォーラムのメモでも度々出てきています(Day1 その1、Day2 その1後半)。委任規則も、Day2のその1後半でふれました。

アカウント情報サービス(定義は、指令4条(16))が提供されると、本人は、一回の登録だけで、あとは、各金融機関に本人の情報が安全に提供されることになって、このように変わっていくということがポイントになります。まさに、eKYC(電子的「顧客確認」)が実現するのです。 (KYCについては、「フィンテックで進むか、 本人確認(KYC)のイノベーション」のリンクを張っておきます)

また、決済開始サービスプロバイダ(PISP)という概念が準備されています。この概念は、他の決済サービスプロバイダにおいて保有されている決済に関するサービスの利用者の求めに応じて、決済命令を開始するサービスを行うものです(同(15)。これが実現すると

のような図になっていきます。

決済サービス指令2のもとにおいては、技術標準119 495において、「電子署名基盤;部門要件;決済サービス指令(2015/2366 EU)における適格証明書プロファイルおよびタイムスタンプポリシ要件」が定められています。

この標準においては、5が、証明書プロファイル要件で、6が ポリシ要件になります。

附属文書Aが、ASN.1 宣言で、Bが、決済サービス指令2を満たす証明書とは、どういうものかということについての解説です。

これらの証明書については、決済開始サービスとアカウント情報サービスが、利用を義務づけられており、銀行におけるアカウントサービスにおいては、利用が強く推奨されています。

決済サービスプロバイダは、その本人性/インテグリティ確認のために、適格電子シールと適格ウエブサイト証明書を利用することになります。

委任規則34条は、各プロバイダの登録番号等の記載とその役割、監督機関の名称が証明書に記載されなければならないことを定めています。

Nick Pope ( Security & Standards Associates)「オープンバンキングにおける適格証明書において呈示された問題点」 ( Open Issues on Use of eIDAS Qualified Certificates in Open Banking)です。

スライドは、一般公開されていません。なので、要点のみをまとめることにします。

要は、適格証明書に関して、PSD2証明書プロバイダーとはどういうことか、証明書を信じることとは、どういうことか、責任とはどういうことか、などの問題が提起されているということだそうです。

とりあえずは、ホームページへのリンクを張っておきましょう。

 

トラストサービスフォーラムinベルリン Day2 その1 後半

次は、「PKIは、どのくらい使われるか(How much PKI is in:PSD2; eIDAS; GDPR)」というArno Fiedler( Nimbus)さんの話です。欧州の規範を利用してeIDASを実装するという趣旨での話です。スライドは、こちらです。

欧州は、現在、デジタル単一市場を目指しており、決済については、SEPA(単一決済エリア)が目指されていることになります。
ここで、特に、決済サービス指令2(PSD2)のための技術的標準をみることになります。
ちなみに、決済サービス指令2の 本文はこちら)で、についての簡単な説明についてはこちらです。

関連する規定としては、

第29条トレーサビリティ

決済サービス提供者は、決済サービスユーザー、他の決済サービスプロバイダー、および商人を含む他の企業の間で確立された通信セッションが、タイムスタンプなどに依拠するように、確かにしなければならない

第34条 証明書

識別のために、(略) 支払いサービス提供者は、規則(EU)No 910/2014の第3条(30)に記載されているような電子シールのための、または第3条(39)第35条に記載されているようなウェブサイトの認証のための認定証明書に依拠しなければならない。

通信セッションのセキュリティ

1 ./ インターネットによるデータ交換に際して、データの機密性および完全性を保護するために、強力で広く認識されている暗号化技術を使用して、各通信セッションを通して通信相手間で安全な暗号化が適用される

とされています。
また、GDPRにおいては、32条の仮名化、32条の取扱の安全措置が、関連してることになります。
eIDAS要件では、5条(データ取扱および保護)、13条(責任および証明の責任)、15条(ユニバーサルアクセス)、16条(罰則)、19条(セキュリティ要件)がかかわってきます。
最後に、欧州のeIDとがブルーワンダーになるようにということで、プレゼンは、終了です。

次は、Andrea Röck(Universign, ETSI STF 524 expert)さんの「ETSIの電子署名と署名検証サービス」(ETSI ESI and Signature Validation Services)というプレゼンです。スライドは、こちら
基本的な内容は、(1)eIDASにおける標準のアップデート(2)署名検証サービスです。
(1)eIDASにおける標準のアップデート
最初にフレームワークは、こちらです。

アップデートされたものとしては、CA Policy Requirements: EN 319 411-1/2、決済サービス指令2のもとでの適格証明書のアップデート、リモート署名に関して、信頼しうるシステムのためのCEN(欧州標準化委員会)標準(EN規格については、こちらhttps://rnavi.ndl.go.jp/research_guide/entry/theme-honbun-400383.php )、生成のプロトコルとコンポーネント要件、内容配達証明、長期保存、トラストリスト、監査要件の補充、機械による取扱の様式があります。具体的なものは、スライドにあげられています。また、最後に、欧州のトラストサービスについての国際的承認の話がでています。

個人的には、「決済サービス指令2(PSD2) のもとでの適格証明書のアップデート」と「欧州のトラストサービスについての国際的承認」が気になるところです。

PSD2については、委任規則が本人確認等についての細かい点を定めています。

具体的には、「2015/2366(EU)指令における強力な利用者識別および通信の一般かつ安全なオープンな標準に関する委員会委任規則(Commission Delegated Regulation (EU) 2018/389 of 27 November 2017 supplementing Directive (EU) 2015/2366 of the European Parliament and of the Council with regard to regulatory technical standards for strong customer authentication and common and secure open standards of communication )」になります。この委任規則の本文は、こちらでみれます。

また、欧州のトラストサービスについての国際的承認」においては、「Study report on Global Acceptance of EU Trust Services」(‘DTR/ESI-000123)があげられています。スケジュールをみることができますが、まだ、早期案の作成中のようです。また、ワークショップがふれられていて、ターゲットとして日本が最初にあがっているのは、興味深いところです。

(2)署名検証
「ETSI STF 524」(特別タスクフォース 524)ですが、これは、2016年に始まり、三つのドキュメントがでています。
TS 119 102-2: Validation Report(https://www.etsi.org/standards-search#search=TS119102-2
TS 119 441: Policy Requirements for TSPs Providing Signature Validation Services(https://www.etsi.org/deliver/etsi_ts/119400_119499/119441/01.01.01_60/ts_119441v010101p.pdf
TS 119 442: Protocol for Signature Validation Services (https://portal.etsi.org/webapp/WorkProgram/Report_WorkItem.asp?WKI_ID=47246
あと、関連のドキュメントもあります。

Matthias Wiedenhorst (TÜVIT)は、「監査報告の苦闘(The struggleofauditreporting)」です。スライドは、こちら

eIDAS3条(18)による適合性評価機構が、国家評価機構としてなす組織は、実質的に唯一であるということになる。

評価の一般的なマトリックスは、TR 119 000, V1.2.1により、 ETSI EN 319シリーズが、トラストサービスプロバイダの監査についてのひとつの欧州の標準ということになる。
しかしながら、監査報告の枠組みについては、いろいろな枠組みが存在することになります。

まずは、ENISAのトラストサービスの適合性評価ガイドライン(Conformity assessment of Trust Service Providers – Technical guidelines on trust services)。(https://www.enisa.europa.eu/publications/tsp-conformity-assessment

ETSI TS 119 403-2 V1.1.1 (2018-07)(https://www.etsi.org/deliver/etsi_ts/119400_119499/11940302/01.01.01_60/ts_11940302v010101p.pdf
ETSI TS 119 403-3(https://docbox.etsi.org/esi/Open/Latest_Drafts/ESI-0019403-3v007-for-public.pdf

結局、ひとつの様式にするのは、現実的ではないとして、誰が、問題点を解決するのであろうかという問いがなされます。

適合性評価機関委員会(ACAB-c)か、FESA(トラストサービス提供者への監督機関フォーラム)か、または、EUか、ということになります。

トラストサービスフォーラムinベルリン Day2 その1前半

CA Day – Wednesday, 24 October 2018

Kim Nguyenさんの簡単なWelcomeのあと、Sławomir Górniak (ENISA)さんの「サイバーセキュリティパッケージと新しいENISAの役割」(The Cybersecurity Package and the new role of ENISA)の講演です。スライドはこちらです。

ENISAは、サイバーセキュリティ法のもとで、サイバーセキュリティ庁として改組されることになり、その説明になります。
個人的には、2010年に調査の関係でクレタ島を訪問したのが記憶にのこっています。

ENISAは、欧州共同体の能力向上、政策立案、専門的分析等をその行動としています。
2017年のユンカー大統領が、サイバーセキュリティ庁としてサイバー攻撃に対抗するということをいったのが、その最初になります。映像は、こちらです。その際のプレスリリースは、こちら

Cyber Security Package 2018は、Day1でも簡単にでてきました。サイバーセキュリティ法関係のドキュメント関係は、こちらです。
サイバーセキュリティ法提案、サイバーセキュリティ戦略、プループリント、「NISの最大利用」コミュニケを考えることができます。

サイバーセキュリティ法(「ENISA(サイバーセキュリティ庁)と情報/通信技術のサイバーセキュリティ認証に関する規則」案)は、こちらです。)

2018年12月11日に、議会と理事会、委員会は、政治的に合意にいたっています(https://ec.europa.eu/commission/news/cybersecurity-act-2018-dec-11_en)。

同法は、6つの目的をもっています。具体的には、
1 EUおよび加盟国レベルでの能力と備えの向上
2 利害関係者の協力と調整を改善する
3 加盟国の行動を補完するためのEUレベルの能力の向上
4 EUにおけるサイバーセキュリティ意識の促進
5 サイバーセキュリティ保証の透明性の向上
6 認証スキームの細分化を避ける
になります。

この提案は、二つのパートからなりたっています。タイトル2は、ENISA-「EUサイバーセキュリティ庁」(3条から42条)で、一方、タイトル3は、サイバーセキュリティ認証枠組み(43条以下)です。より、強制的な政策が必要であることから、適切な資源があって、永続的な立場を与えるということで、ENISAの役割を強化する必要があったわけです。
より強靱なENISAは、法律と政策の任務、能力構築、運営協力、市場と認証、意識向上、研究とイノベーション、国際協力を課題とするわけです。

前者は、ENISAを強化し、補強するもので、特に、政策策定と実施の役割、 業務協力の役割 – ブループリント、 研究資金プログラムへの参加の点について変更が加えられています。

後者は、「EUレベルのサイバーセキュリティ認証の枠組み」であって、 候補スキームの作成におけるENISAの役割、 「欧州サイバーセキュリティ認証グループ」のためにENISAが提供する事務局的支援が述べられています。

後者についてみていきましょう。認証については、

「「特定の要件を満たしていることの証明と公正な第三者認証の提供」もしくは、「「定義された一連の基準規格に対する独立した認定機関による製品、サービス、およびプロセスの正式な評価、および適合性を示す証明書の発行」という定義がなされています。もともとは、コモンクライテリアによってさだめられていたところです。各国における相互承認は、SOG-IS(情報システムセキュリティ上級グループ-)による相互承認協定によっています(https://www.sogis.org/)。

EU戦略の全体像との関係については、Day1のとおりです。

この枠組みの特徴は、国家ICTセキュリティ認証イニシアチブによる断片化を回避、相互承認を促進する、保証レベル(基本、実質、高)を定義する、手順を簡素化し、IT製品とサービスの展開にかかる時間とコストを削減する、ヨーロッパの製品とサービスの競争力と品質を向上させる、購入するICT製品やサービスに対するユーザーの自信を高めるの特徴を有しています。

提案された枠組みにおける重要な要素は、範囲(過程、製品、サービス)、参照される標準、適合性評価機関のためのサイバーセキュリティ要件、申し込み者によって適合性評価機関に提供される情報、マーク・ラベル利用/証明書の条件、適合性に関するモニタリングルール、脆弱性報告のルール、証明書の内容(機関、開示、相互承認)です。

トラストサービスフォーラムinベルリン Day1 その4

15時30分から16時45分までは、「トラストサービスのあらたな機会-リモート・サイニング」というパネルです。登壇者は、Evgenia Nikolouzou (NISA)、Kim Nguyen(D-TRUST)、Adreas Kuehne (OASIS, trustable)Andrea Röck (Universign, ETSI STF 539 expert)Jon Ølnes (Signicat) です

最初は、Andreaさん(ETSI)です。スライドは、こちらです。Universign についての紹介が簡単になされました。

ETSI 特別タスクフォース(STF) 539は、3つのドキュメントを明らかにしています。TSP119 -431-1は、「リモート(適格)署名製造機器を運営するトラストサービス提供者のコンポーネントのポリシおよびセキュリティ要件」です。これは、コンポーネントについてのものになります。TSP119 -431-2は、「先進署名製造機器をサポートするトラストサービス提供者のコンポーネントのポリシおよびセキュリティ要件」です。TSP119 -432は、「リモートデジタル署名作成のためのプロトコル」です。

問題点としては、電子署名・電子シールの状況を明確化するということ、と電子署名生成装置の認証の限界点ということです。

Adreas(OASIS)さんは、このスライドです。

OASISの活動をアップデートになります。DSS-Xは、デジタル署名をウエブサービスで進めるためのインターフェースを提供することにしており、その新たなバージョン2を公表したことになります(2年前)。DSS-Xのプロファイルは、ローカル署名の委員会のドラフトの段階ですが、鍵の設置については、種々のバリェーションがあります。

将来の姿については、こちらです。

 

次はJonさんです。スライドは、こちら。Signicatという会社のご説明からです。

ポイントとなるのは、このスライドでしょうか。

利用者としては、署名の必要性が生じたときに、フロントエンドでの署名、IDの提供をうけること、場合によっては、タイムスタンプを付すこと、その他の方法を用いることなどが、選べることができるとされています。

また、連携電子署名の考え方が紹介されています。Signicatという会社はIDプロバイダの証明に基づいて署名をなして、場合によっては、他のサービスとも連携します。

その一方で、適格電子署名が回答なのか、きわめて高価であって、ノルディック諸国においては、適格電子署名が求められていないということもあります。

そのあと、フロアでの質問に移行しました。

このセッションでは、市場でのニーズがあるのか、という議論がなされたのは、興味深かったです。回答では、リモート署名のみがニーズがあるのではないか、という回答がなされていました。一方では、ドイツでは、適格電子署名は、成功してきました、という回答もなされており、いろいろいな状況のようです。また、適格かどうか、違うのか、というのについては、いろいろいな状況があって、それは、国にも状況にもよるだろうという回答もなされました。