前のエントリに引き続いてEU eHealth Networkの接触追跡のツールボックスき分析です。
Ⅲ モバイル接触追跡および警告アプリに共通のアプローチと、付録Ⅰ モバイル追跡アプリに共通のアプローチのための推奨事項 が、ポイントになります。
付録Ⅰで、国家的アプリとクロスボーダー相互流用性についての基本的な要求事項の解説がなされています。これでもって分析することにします。（ガイドラインも公表されているので、そっちもみたいですし）
要求事項は、
- 疫学的枠組
- 技術的機能
- 重要なクロスボーダー相互流用性要求事項
- サイバーセキュリティ
- 安全措置
- アクセス可能性および包摂性
にわたって記載されています。
疫学的枠組（Epidemiological framework，EF）
アプリは関連する公衆衛生当局の管理下で運用する必要があること、
その既存の疫学的プロセスと手順をサポートおよび補完するために、公衆衛生当局と協力してなされるべきこと、 公衆衛生当局は、 国内の法律および国際的なガイダンスに従つて、 地域の連絡先追跡プロセスを調整する必要があること、フォローアップする必要がある連絡先と連絡先の管理方法を定義すること、 ユーザーが、 アプリのアクティブ化に同意する前に、 フォローアッププロセスについて十分に説明する必要があること
などを意味します。要点を示すと、
| 機能／アプリのタイプ | 記述および推奨事項の要旨 | 関連当事者 | |
| EF-01 | 「濃厚接触」の疫学的関連性 | 疫学的に十分な近接性の採用 | 公衆衛生当局/ECDC |
| EF-02 | 接触追跡データの保持期間についての疫学的関連性 | ECDC(欧州疫学センタ)により合意された履歴保持期間(14または16日) | ECDCガイダンス/公衆衛生当局 |
| EF-03 | (接触リスクある)利用者への情報 | 接触リスクのある利用者への通知の方法や安全措置について | 関連する公衆衛生当局 |
| EF-04 | (接触リスクある)利用者への通知タイミング | 検査で陽性がでたらただちに通知すること | |
| EF-05 | COVID-19(感染)状況のエンコード | 公衆衛生当局または研究所のみが、陽性を確認し、警告を発しうること | |
| EF-06 | 利用者に提供される情報 | 接触者への連絡とそれからの対処方法の連絡 | |
| EF-07 | 公衆衛生の努力を支えるプライバシー尊重アプリ・ソリューション | 個人データの取扱いを最小限にする方法(分散取扱/バックエンドサーバー構成) |
となります。
技術的機能
技術的機能の定義というのは、特に説明はいらないでしょう。具体的には、
なお、TF-03におけるエフェメラルIDの説明については、こちらをどうぞ。
| TF-01 | 近接技術 | 1.5メートルの距離を決定できること、偽陽性を最小化するために0.5メートルの解 像度であること |
|
| TF-02 | 物理的近接性 | 実際の物理的近接性が正確に記録されること | |
| TF-03 | エフェメラル(短時間) ID | エフェラルIDは、ランダムな仮名として生成され、盗聴やハッキング、追跡からの防護のために、定期的に変更されること(なお、この点は、 BlueTraceのホワイトペーパーにもありました) |
|
| TF-04 | COVID-19の感染を確認するための保健当局によって生成されるコード | ランダムで名称がわからない一時的なコードによって、確認がなされること | 公衆衛生当局 |
| TF-05 | スケーラビリティ | 1月において、10億人が利用しても大丈夫なスケーラビリティ | |
| TF-06 | 機器 | ブルートゥースの接続が可能なすべての機器で、利用可能であること(OSを問わない、バッテリを食わないこと) | |
| TF-08(ママ) | オープンソース | 技術的仕様やソースコードがオープンであること | アプリ開発者 |
国境を越えた相互運用性
これは、
追跡および警告アプリは、デバイスがEU内のどこにあるかに関係なく、前記の機能を実行できるように、特にプライバシーおよびデータ保護の権利を保護するために、共通のEU相互運用性プロトコルに従うべきである。
というものです。
この付録の表は、節によって、項目が、叙述調になっていたり、TF-07が欠番だったりと、結構、突貫工事だったことを伺わせます。というか、勧告では、15日に出口戦略と一緒に公表するはずといっていたのに、一日遅れていたりします。
| IOP-01 | eHealth 欧州相互流用性枠組 | 欧州における枠組に準拠していること | eHealthネットワーク |
| IOP-02 | 高リスク濃厚接触のための疫学的クライテリア | 濃厚接触および保存期間の統一 | ECDC/WHO アプリ開発者 公衆衛生当局 |
| IOP-03 | 別アプリ利用者においても利用可能なこと | アプリ開発者/公衆衛生当局 | |
| IOP-04 | バックエンドの相互流用性 | 国境を超えたデータの相互流用性を確保すること | アプリ開発者/公衆衛生当局 |
| IOP-05 | 感染通知 | 保健衛生当局が、情報提供プロトコルで一致すること | 公衆衛生当局 |
サイバーセキュリティ
これは、国に対する要求事項と開発者に対する要求事項に分かれます。
| 国家に対する要求事項 | |||
| CS-01 | 国家的リスク評価、情報共有、インシデントレスポンス | アプリに対する国家的サイバーセキュリティのリスク評価すること | |
| CS-02 | セキュリティテストおよび独立評価 | 国家機関によるセキュリティの確保、バックエンドの評価 | |
| 開発者に対する要求事項 | |||
| CS-03 | データ最小化および最小権限 | ||
| CS-04 | セキュアなソフトウエア開発 | 開発者が、グッドプラクティスに従うこと、セキュアデザイン原則、セキュアコーディング原則に従うこと、など | |
| CS-05 | アプリ、プロトコルおよびバックエンドにおいてセキュリティがビルトインされること | スマートフォンのOSにビルトインされているセキュリティ機能を最大限に利用すること | |
| CS-06 | 通信セキュリティ、暗号化、暗号技術 | ||
| CS-07 | セキュリア・バイ・デフォルト/ユーザーフレンドリー | ||
| CS-08 | 利用者認証 | 重要情報にアクセスする場合は特に、スマートフォンの利用者認証システムを利用すること | |
| CS-09 | ライブラリと第三者コード | サードパーティライブラリへの依存は避けることなど | |
| CS-10 | セキュアでないスマートフォーンの利用 | 開発者は、すべてのスマートフォンが、最新ではないことに留意すべき | |
特に、CS-10は、大変な課題になりそうです。アンドロイド派の私としては、開発者さんご苦労さまですとしかいいようがないです。
あと、参考文献もあがってます。
ENISA
– ENISA Smartphone guidelines and tool: https://www.enisa.europa.eu/topics/iot-and-smart-infrastructures/smartphoneguidelines-tool
– ENISA report on pseudonymisation techniques: https://www.enisa.europa.eu/publications/pseudonymisation-techniques-andbest-practices
Industry
– OWASP mobile security project https://owasp.org/www-project-mobile-security/ ,
– OWASP Mobile Security Testing Guide https://owasp.org/www-project-mobile-security-testing-guide/
– Android developers security documentation- https://source.android.com/security
– iOS developers security documentation- https://developer.apple.com/documentation/security
安全措置
| SG-01 | 一時的アプリ/データの消去 | 危機終了後においては、動作を停止し、個人情報・近接情報が消去されること | |
| SG-02 | 自主的性格 | 意図された取扱いのみに同意ベースであること | |
| SG-03 | 追跡なし | 位置情報は必要ではなく、アプリとしては、推奨しない | |
| SG-04 | 烙印(スティグマ)なし | 感染者が誰であるか、というのがわからないような仕組みにすることを確かにすること | |
| SG-05 | 近接データの機器への保存 | 濃厚接触データは、機器のみに保存されること、一定期間経過後に消去されること、 | |
| SG-06 | ID生成 | 短期的IDは、仮名で作成され、定期的に変更されるべきこと | |
| SG-07 | 仮名 | 名称を付する場合には、個人識別情報(PII)とは関係なしにすること | |
| SG-8 | 暗号 | できる限り暗号化すること |
アクセス可能性および包摂性
| M-01 | アクセス可能性記述 | EUにおけるWebアクセス可能性指令などの要求事項を満たすべきである | |
| M-02 | UX基準 | CEN/ISO 82304-2の品質要求事項適合性評価 (Quality Requirements Conformity Assessment (QRCA))の作業を参照する |
あとは、保健当局のガバナンスや補助的活動となるので、省略します。
これらの要求事項をどう考えるのか、ということになります。このようなアプリに本質的に必要な事項とGDPRについて、公衆衛生例外を発動させないことから生じている要求事項があるように思えます。
個人的には、この事態において、「公衆衛生例外」を発動しない、というのは、どう考えてもおかしいと思うので、この点は、別の機会に論じてみることにしましょう。
