userUuid および secret の廃止

[nov]

現在アプリ初回起動時にuserUuidという永続的なアプリインスタンス識別子と、それと1-1で紐づくsecretというトークンを発行して、感染報告時にTEKと同時にそれらをサーバーに送っています。

これらの識別子およびトークンは14日間というスパンを超えて永続的に利用可能な識別子であり、Apple / Googleが14日間を超えたトラッキングを防ぐために採用している識別子発行ポリシーに逆行しているように思われます。

これらの識別子およびトークンの利用を撤廃してはいかがでしょうか？

[kazumihirose]

ご提案ありがとうございます。

UserUuid / Secretは二つの役割を持っていまして。
UserUuid・Secretは発行時にお考えの通りにアプリに格納されています。
SecretはRegister以後のAPIを保護する為に利用している、AES256のキーです。（ユーザー個別に発行されています。）

では、UserUuidは何に利用しているかといいますと、Optoutの為です。
Apple/GoogleのEN実装では、EUでも承認されたものの本来はGDPRが考えるOptoutが対応されていません。
よって、Optoutの考え方が無い為、サーバ側は一度送信された診断キーを14日間保持し、クライアントに送信された診断キーがシーケンシャルに読み込まれます。

この過程と同様に私たちも考えたのですが、本来論のGDPRに対応する為にも、14日間経過前に削除するというOptoutがあったほうが良いのではないか？との考えに至っています。（もちろん本来の実装にはありません。）
この点は私たちもとっても悩んだところでした。

Optout APIはサーバ側は配備されており、今後クライアントに実装する予定ですが、このAPIの呼び出しによって該当UserUuidとSecret、そして診断キーをDBから全削除し、ユーザーが送った一切のデータは削除される仕組みとなっています。

廃止される事によって、GDPRには準拠できなくなるのですが、この辺りのお考えと他に良い方法などあれば私たちもうれしいです。

[nov]

optoutと言っているのは、何のoptoutのことでしょうか？

[kazumihirose]

ユーザー自身の登録データの削除です。
Optoutによって、こちらのDBからはUserUuid / Secret / アップロードされた診断キーのユーザーすべてのデータを削除してしまいます。

[nov]

それはTEKリストを送ってそのTEKを削除するのではなく、UUIDを用いて2週間以上の長期にわたってユーザーを識別し続けなければ実現出来ないものなのでしょうか？

[kazumihirose]

TEKリストを送って、クライアント側で削除ってできるのですか？だとすると把握していない可能性があるので、教えてください。

[nov]

クライアント側での削除ではなく、クライアントからサーバーに送ったTEKリストをサーバー側で削除したいということではないのでしょうか？

であれば、クライアント側から再度削除してほしいTEKリストを送れば良いかと。

[kazumihirose]

えっと、その場合なのですが、クライアント側から送られてきたTEKがそのスマートフォンのアプリであると、どの様に一致させたら良いでしょうか？
そのような仕様ってありましたっけ・・・OS側からAPIで受け取ったTEKは一度送信すると再取得がOSからできないはずでして、アプリ内で保存する事もできなくもないのですが・・・それは出来ればやりたくないのです。

[nov]

その検証が必要な理由はよくわからないのですが、それを検証する必要があるのであれば、TEK送信後一定期間のみ有効な識別子を生成するのが良いのではないでしょうか。

[kazumihirose]

送信時UUID生成は良いですね。
あとはSecretなのですが、これは残したままになりますが、どうしましょうか・・・
その場合、RegisterAPI以外のAPI保護方法を再検討する必要があるのですが、どうお考えになりますか？

[nov]

どのAPIをどういった攻撃から保護したいのかはよくわかりませんが、API保護よりも14日以上永続化されてしまう識別子を排除することが求められているアプリかと思います。

[kazumihirose]

陽性登録APIです。
陽性登録は非常にリスクの高いAPIで、場合によってはテロ行為として扱われ、パニックを意図的に起こすなどの懸念もあります。既にAPIレベルのキーは、本日のリバースエンジニアリングを行われたホワイトハッカーの皆様で破られています。クライアント証明書の導入は検討していますが、これもリバースエンジニアリングで破られます。
無い場合は、いわゆる丸裸で運用する事になるのですが、他に何か良い策ありませんでしょうか？

[nov]

そのために「処理番号」なるPINのようなものを発行しているのではないですか？

現状UUIDやSecretはRegister APIさえ叩いてしまえばいくらでも発行できるようなので、特にSecret単位でアクセス数等を制限しても効果は見込めないかと思います。

[kazumihirose]

この点については、私たちだけでの判断では、ちょっと厳しいので、この提案について政府の担当さん通じて少し相談するお時間をくださいませ。

[sakimura]

ちゃんと追わないでやや無責任な言説なのでおかしければ聞き流してください。送信時にuuidを送りシークレットで認証するより、送信時に鍵ペアを生成して、公開鍵を識別子として送信、APIアクセス時にはnonceを含むリクエストにsecure enclaveで保護している秘密鍵で署名して送ればよくありませんか？破るのはかなり困難になると思いますが。

[tzik]

鍵ペアである必要もないかと思います。
Diagnose APIで送信するデータにクライアント側でランダムに生成したtokenを添えておき、OptOut APIでも同じtokenを送ってもらって、サーバー側ではtokenに紐付いたTEKリストのみ除けばよいのでは。

[darkcrash]

ご意見、ご提案ありがとうございます。

現行のSecretを削除するとき問題点として以下の認識です。
（まだほかにもあったらごめんなさい）

1. DignosisApiの保護が薄くなる。
   Secretでの案として、古典的ですが、Uuidによる連続したアクセスによる攻撃、ブルートフォースアタックに対応する。生成時から一定期間は自己診断登録を拒否するなど。

2. 悪意あるユーザーによってDignosisApiから呼び出されるサービスに負荷をかける可能性がある
   すべてを丸投げすることもできなくはないですが、呼び出されるサービス側がそれを拒否しなければいけない状況を生み出す可能性があります。

3. DiagnosisApiに提出した内容を削除できなくなるか、他人の登録したデータを勝手に削除できてしまう可能性がある。
   個別Secretでの案として、OptOutのための自己診断データに対する利用者の権利と保護を考えていました。

ご提案として3.の解決策をいただきました。
しかしながら、1.および2.の対策が弱い状況なので、このままでは踏み込むのは難しいと考えています。

[tzik]

処理番号に電子署名を付けてフロントエンド内で検証できれば1,2についても解決できそうですが、その部分を変えるのは難しいでしょうか？
現状の数値8桁の番号では虚偽申告を排除できず、どのみち拡張する必要があるように見えます。

[sakimura]

@tzik さんが仰るように、1, 2 は、より確実な形で解決できています。

単に(bearer) token でよいのではないかという点については、想定する攻撃者モデルによるということになります。テロを想定するのであれば、かなり強い攻撃者を想定することになるので、送信されたトークンは読むことができるnetwork attacker を想定すると思います（名前に反し、必ずしもトークンはネットワーク上で読まれるとは限りませんが）。このような場合、上記のような鍵ペアの利用は有効です。

[darkcrash]

すいません。私が理解に至ってないようです。

電子署名の元となるものは、公開キーになるということでしょうか？
それとも、最初の段階でUserUuidに代わり秘密キーを発行するということでしょうか？

[darkcrash]

単に(bearer) token でよいのではないかという点については、想定する攻撃者モデルによるということになります。テロを想定するのであれば、かなり強い攻撃者を想定することになるので、送信されたトークンは読むことができるnetwork attacker を想定すると思います（名前に反し、必ずしもトークンはネットワーク上で読まれるとは限りませんが）。このような場合、上記のような鍵ペアの利用は有効です。

ユーザーデータの保護という意味での、トークンを読むことができるという点については確かにそうで、これはクライアント証明書によるエンドポイントの保護を考えています。
クライアントに公開証明書を用いて、サーバーに秘密キーを持つ証明書でのTLSを用いると。

[darkcrash]

問題としての１と２は、
陽性登録API（DiagnosisAPI、自己診断提出API）は悪意あるユーザーからのアプリ全体の保護で、利用者全体に対するものと考えています。これを実現するために、個人情報を含まない形での識別がSecretというものにもなっています。匿名アクセスを前提とする場合、平等であるがゆえに誰でもアクセスすることができる。つまり、攻撃をそのまま受けてしまうことを意味していると考えておりました。
前提としてアプリに埋め込んだリソースは抜き出すことが可能で、これは公開した情報と同等と考えています。

[tzik]

すいません。私が理解に至ってないようです。

電子署名の元となるものは、公開キーになるということでしょうか？
それとも、最初の段階でUserUuidに代わり秘密キーを発行するということでしょうか？

言葉足らずでしたね。すみません。
感染者管理システムが鍵ペアを持ち、検査陽性者には電子署名付きの処理番号を発行し、陽性者登録APIに渡してもらいます。
Diagnosis APIの受け口には公開鍵を持たせておき、陽性者登録時に署名の検証をし、正当でないものは棄却します。
署名付きの登録番号を持たない攻撃者に対してはそのまま棄却し、登録番号を持つ攻撃者に対しては、番号ごとにrate limitをかけるか、使用回数に上限をつける、というのを想定していました。

[tzik]

@tzik さんが仰るように、1, 2 は、より確実な形で解決できています。

単に(bearer) token でよいのではないかという点については、想定する攻撃者モデルによるということになります。テロを想定するのであれば、かなり強い攻撃者を想定することになるので、送信されたトークンは読むことができるnetwork attacker を想定すると思います（名前に反し、必ずしもトークンはネットワーク上で読まれるとは限りませんが）。このような場合、上記のような鍵ペアの利用は有効です。

MITMが成立している想定でのモデルはあまり考えたくはないのですが、その想定だと送った公開鍵がすり替えられることまで気にする必要がありませんか。

[nov]

1, 2 については、保健所から発行される処理番号が保護の役目を果たしていると認識しているのですが、違いますでしょうか？

[methane]

感染者管理システムが鍵ペアを持ち、検査陽性者には電子署名付きの処理番号を発行し、陽性者登録APIに渡してもらいます。

電子署名である必要はありますか？処理番号が十分に推測困難ではないとしても、スマホの操作に不慣れなユーザーでも簡単に入力できるように、8桁くらいのパスワードを組み合わせるので十分ではないでしょうか。

[tzik]

感染者管理システムが鍵ペアを持ち、検査陽性者には電子署名付きの処理番号を発行し、陽性者登録APIに渡してもらいます。

電子署名である必要はありますか？処理番号が十分に推測困難ではないとしても、スマホの操作に不慣れなユーザーでも簡単に入力できるように、8桁くらいのパスワードを組み合わせるので十分ではないでしょうか。

悪意あるユーザーによってDignosisApiから呼び出されるサービスに負荷をかける可能性がある

らしいので、裏にあるサービスにアクセスすることなく正当性を検証できる必要があるように思えます。

[shogo82148]

「裏にあるサービス」とはなんのことでしょうか？

[nov]

ここでは厚労省のポリシーや保健所が発行するコードの仕様変更を伴うような全体アーキテクチャに関する議論を行うのはあまり効果的ではないようなので、こちらのツイートで公開されている厚労省の連絡先に連絡させていただきました。
https://twitter.com/kazumihirose/status/1274639502716198914?s=21

こちらから Close してしまって良いのか判断しかねますが、個人的にはこれはこのオープンソースアプリ単体で解決できる問題とも思っていないため、私としては Close いただいて結構です。

[Cat-sushi]

技術的な公開議論にはGithubが便利ではないでしょうか。
Openしたままのこちらを参照するのが早道かと思います。

[sakimura]

既に必要ないかもしれませんが、一応。

@tzik さんが仰るように、1, 2 は、より確実な形で解決できています。
単に(bearer) token でよいのではないかという点については、想定する攻撃者モデルによるということになります。テロを想定するのであれば、かなり強い攻撃者を想定することになるので、送信されたトークンは読むことができるnetwork attacker を想定すると思います（名前に反し、必ずしもトークンはネットワーク上で読まれるとは限りませんが）。このような場合、上記のような鍵ペアの利用は有効です。

MITMが成立している想定でのモデルはあまり考えたくはないのですが、その想定だと送った公開鍵がすり替えられることまで気にする必要がありませんか。

遅レスすみません。読めるのと変更できるはまた攻撃者の強度が異なりますね。書換も自由だとちょっと手立てが難しくなりますが、前記のネットワーク攻撃者だと、TLSで守られているチャネルで伝送される情報は読めるけど書き換えられないという前提で、それなりに納得性があるものだと思います。この前提であれば、処理番号が安全に渡されかつ十分なエントロピーがあれば、公開鍵の登録時にやられるというのは、TLSは安全であるという前提に反するので無くなることかと思います。

[sakimura]

ユーザーデータの保護という意味での、トークンを読むことができるという点については確かにそうで、これはクライアント証明書によるエンドポイントの保護を考えています。
クライアントに公開証明書を用いて、サーバーに秘密キーを持つ証明書でのTLSを用いると。

これ、クライアントはモバイルアプリですよね。とするとクライアント証明書を使う場合は全てのインスタンスで別のということになります。そこまでするメリットはあんまりないと思うのですよ。raw keysで十分ではないでしょうか？

[Yuutakasan]

こう言う意見も書かないと一方的な意見だけになってしまうのであえて書きますが、
個人的にはこの緊急事態において、コストと時間をかけて情報保護をする必要ってないと思います。

政府がそこまで信用できないのであれば、アプリのインストールをしなければいいだけであり、
そもそも政府が信用できない人はどこまでやったってアプリのインストールをしないと思いますし、
不安ならアンインストールしてもらえれば、UUIDと個人を紐づける事はできないはずなので、それで解決では？

今の実装に同意できる人だけアプリをインストールしてもらえれば十分なので、
個人的には今ので実装でも十分だと思っています。

[darkcrash]

ユーザーデータの保護という意味での、トークンを読むことができるという点については確かにそうで、これはクライアント証明書によるエンドポイントの保護を考えています。
クライアントに公開証明書を用いて、サーバーに秘密キーを持つ証明書でのTLSを用いると。

これ、クライアントはモバイルアプリですよね。とするとクライアント証明書を使う場合は全てのインスタンスで別のということになります。そこまでするメリットはあんまりないと思うのですよ。raw keysで十分ではないでしょうか？

個別は現実的ではないですね。 rawkeys がなんとなく同じ認識になる気がしましたが・・・
すいません、私の知識不足でわかっていません。

[wfukatsu]

政府がそこまで信用できないのであれば、アプリのインストールをしなければいいだけであり、
そもそも政府が信用できない人はどこまでやったってアプリのインストールをしないと思いますし、
不安ならアンインストールしてもらえれば、UUIDと個人を紐づける事はできないはずなので、それで解決では？

今の実装に同意できる人だけアプリをインストールしてもらえれば十分なので、
個人的には今ので実装でも十分だと思っています。

普及率の目標次第でしょうね。

スマホの普及率が77.6％（2020年）、今回のアプリの効果を得るには、国民の60%以上の導入が必要とのことなので、スマホ保有者の80％近くがインストールしている必要があることを考えると、重要なテーマだと思います。

政府は信用できなくても、システムやアプリは信頼できるという状態が担保できれば、国民の多くの方たちへの普及に繋がると思います。

[Cat-sushi]

appsupport@cov19.mhlw.go.jp
に#535 とB. Secretを無くすをセットで提案しようと思ったところで、私が理解していないことが判明しました。
UserUuidとseacretは専らオプトイン→オプトアウトしたときにサーバにある2週間分のサーバデータを安全に消すことが目的で、それが不要であれば無用の長物でしょうか。
#535 とは関係ないのでしたっけ？

[darkcrash]

appsupport@cov19.mhlw.go.jp
に#535 とB. Secretを無くすをセットで提案しようと思ったところで、私が理解していないことが判明しました。
UserUuidとseacretは専らオプトイン→オプトアウトしたときにサーバにある2週間分のサーバデータを安全に消すことが目的で、それが不要であれば無用の長物でしょうか。
#535 とは関係ないのでしたっけ？

たしかに直接関係はないのですが、意図として保護したいというのはありました。
#535 では桁数の議論も進んでいるようですが、８桁の話はここにあるものではないため、あまり現実的ではないかもしれません。
以下がその仕組みとしての実装になります。

https://github.com/Covid-19Radar/Covid19Radar/blob/master/src/Covid19Radar.Api/Services/CustomVerificationService.cs

接続先含めてソースコードに含めるというわけにはいかないのでこのような形になっています。
単純にここにある桁数を挙げて取り込んでいったとしても相手側が8桁以外になるというわけではないですね。おそらくは単純にエラーが返ってきてしまいます。

[Cat-sushi]

@darkcrash
なりすまし防止ですよね。
そもそもなりすまし防止が必要、という議論と、オプトアウト時のサーバデータ削除にもなりすまし防止が必要という議論があると。

[Cat-sushi]

接続先含めてソースコードに含めるというわけにはいかないのでこのような形になっています。
単純にここにある桁数を挙げて取り込んでいったとしても相手側が8桁以外になるというわけではないですね。おそらくは単純にエラーが返ってきてしまいます。

すみません、理解できませんでした。
処理番号の桁数変更にはシステムマイグレーション戦略も必要、というような話ですか?

[darkcrash]

すみません、理解できませんでした。
処理番号の桁数変更にはシステムマイグレーション戦略も必要、というような話ですか?

処理番号のフォーマット・生成は、私たちがここから直接関与できるものじゃないという点ですね

[Cat-sushi]

@darkcrash

処理番号のフォーマット・生成は、私たちがここから直接関与できるものじゃないという点ですね

はい。だからこそ、appsupport@cov19.mhlw.go.jp にメールだと思っています。

verificationPayload (REQUIRED FOR VERIFICATION PROTOCOL)
Type: String
Description: verificationPayload is a signed certificate from a public health authority, indicating a confirmed diagnosis

と・・・気づけばJWTになってますね。

えっと、そもそも8桁整数じゃAPI仕様を逸脱?

@wfukatsu

処理番号は、そのまま送信して、別途署名を送るのが現実的だと思います。
陽性者が検査結果を通知される際には、PCR検査という物理接触があるので、ここで鍵やシークレットを交換しておくのがよいのでは？

8桁整数を秘密鍵で署名すると、何ができるようになるのでしたっけ?
エントロピーは上がらないけど、なりすましは防止できる？
でも上記のAPI仕様は満たさない、ですかね?

私も諦めるつもりはありませんが、よりよくわかっている方も厚生労働省に提言いただけると、効率的かと思います。

[t-yamo]

@Cat-sushi @darkcrash
おそらくほぼ #514 ではなく #535 の範囲の話題に推移しているかと思いますので、そちらで続けた方がよいかもしれません。

[darkcrash]

@t-yamo
ありがとうございます。そうですね。ちょっと移動しましょうか

[Cat-sushi]

@t-yamo @darkcrash
拝承、ですが、UserUuidとsecretは廃止で良かったんでしたっけ。

[darkcrash]

@Cat-sushi
廃止すべきという多数の意見をいただいていますね。
私個人としても廃止するということでよりシンプルになることは良いと思います。
しかしながら、現状を踏まえたときすぐに廃止と言い切れない部分があるとは思います。
結論としてはそこに達しながら、関連したものを整理しないとというところでしょうか。

[GiegGissing]

WebAPIを呼ぶタイミングを変えて欲しいです。

UUIDとかsecretは難しくてわからないのですが下記の不安があります。

陽性登録したならば追跡されても仕方がない。むしろ協力する。
しかし、アプリ利用だけで追跡の可能性が残るならば使いたくない。

目的はアプリ利用者を少しでも増やすことだと思います。
利用規約への同意ボタン押下時にWebAPIを呼ぶのではなく、
陽性登録時に初めてWebAPIを呼ぶことに何か不都合がありますか？

WebAPIの返却値と端末が紐づけできるのかはわかりませんが、
難しい説明より、必要ないものはやり取りしない方がわかりやすいです。
近い将来に予定されている利用法があるのでしょうか？

＃修辞疑問（？）の使い方合っていますか？

[darkcrash]

WebAPIを呼ぶタイミングを変えて欲しいです。

そうですね。変えること自体難しいことではないんです。
むしろ削除してしまうだけでよい。
しかしながら、不透明とか不安というものについては、ここのソースコードが元になってることで第三者が検証可能とするというのがもともとの方針です。

なので少し前にも申し上げた通り、不安や不透明、表現がという理由で文章校正のように変えてしまうとそれはそれで大変なことになります。
不要として削除にできるだけもっていきたいところですね。

[GiegGissing]

より正確には、WebAPIを呼ぶタイミングを戻して欲しいです。

陽性登録の前のプライバシーポリシー確認付近に在ったものが、チュートリアルや利用許諾の追加によって実装位置が元々意図されていたと思われるタイミングではなくなっているからです。

[darkcrash]

より正確には、WebAPIを呼ぶタイミングを戻して欲しいです。

陽性登録の前のプライバシーポリシー確認付近に在ったものが、チュートリアルや利用許諾の追加によって実装位置が元々意図されていたと思われるタイミングではなくなっているからです。

UserUuid/Secret の廃止ではなくてですか？
理解がいたらず状況がよくわかっていませんが、RegisterAPIが、アプリ利用開始時にある同意画面ではなく陽性登録直前にということでしょうか？

その前提での話であれば、
一つは陽性登録APIを守るための識別子でした。
時間を持っているため、発行してからすぐに陽性登録するとか、陽性登録を適当な値でひたすら実行する場合の保護です。

なるほど・・・発行してからすぐに陽性登録という点が失われるくらいで、妥協案としては良いかもしれません。

[darkcrash]

処理番号登録での対策今のところ見つからず、
時間もないために、妥協案

より正確には、WebAPIを呼ぶタイミングを戻して欲しいです。

を取り入れつつ、いくつかの対策を残しておこうかと思います。
もし見つかれば、この対応ごと消してしまえば良いと考えます。
これどう思います？

[Cat-sushi]

@darkcrash
どういう意味ですか?

しかしながら、現状を踏まえたときすぐに廃止と言い切れない部分があるとは思います。
結論としてはそこに達しながら、関連したものを整理しないとというところでしょうか。

概ねUserUuidとsecret削除の方向だが、#535, #565, #566 解決までの暫定作としてWebAPIを呼ぶタイミングを戻すという意味ですか。

[darkcrash]

@Cat-sushi
そうです。陽性登録をある程度守れる策が今は見つからず、時間だけが過ぎていくと何もできなくなりそうなので、一つの手として動かしていくという暫定対策です。影響範囲はかなりあるのですが、廃止に向けた場合でも通る道なので、すべてが無駄になることもないでしょうし。

[kazumihirose]

こちらは厚生労働省によって運用されているCOCOAのコードではありません。
大変恐縮なのですが、厚生労働省(COCOA)に再度Issue/PRなど頂ければ幸いです。
何卒宜しくお願い致します。