BETA

「COCOA」の実装はプライバシーに最大限配慮したものにはなっていない

投稿日:2020-08-08
最終更新:2020-08-15

新型コロナの接触確認アプリCOCOAは、どうあるべきだったのか?という記事にて以下のような記述を見かけました。

COCOAの仕様は、プライバシーに最大限配慮したものになっています。

プライバシーという言葉が指すものが曖昧ですが、上記の記事ではCOCOAの仕様について取り扱っているため、政府CIOポータルで公開されている接触確認アプリ及び関連システム仕様書プライバシー及びセキュリティに関する評価報告書の記載内容を前提とします。

そして、COCOAの仕様がプライバシーに最大限配慮したものだとすると、COCOAの現在の実装はプライバシーに最大限配慮したものにはなっていないように見えます。(*1)

COCOAの仕様に対するプライバシー評価

評価報告書ではCOCOAの使用する識別子について、プライバシーの観点から評価を行なっています。

Page 3
処理番号とは、陽性者からの要求を受けて感染者システムから発行する無意かつ一次的な番号である。
感染者システムの管理者でもある厚生労働省では、どの処理番号がどの陽性者に割り当てられているかを把握していることから、処理番号によって特定の個人を識別することが可能である。
したがって、処理番号は行個法の定める個人情報となると考えられる。
さらに、処理番号は、陽性者であると医師等に診断された個人にしか発行されない番号であるから、当該処理番号によって特定される個人は、陽性診断を受けた者であることが明らかである。したがって、処理番号は行個法の要配慮個人情報に該当するといえる

診断キーについては、原則として個人情報に該当しないと考えられるが、本アプリ運営者が、診断キーと個人情報である処理番号を紐づけることによって、診断キーから特定の個人を識別することができる場合には、診断キーも要配慮個人情報に該当

また、個人情報、要配慮個人情報に該当しうる識別子については、不要になった段階で速やかに削除されていると評価されています。

Page 7
(6)利用する必要がなくなったプライバシー情報の消去
本仕様書によれば、端末内の日次キー及び接触符号、並びに通知サーバー内の診断キーは、それぞれ取得から 14 日間の経過後に消去することとされている。
また、通知サーバー内の処理番号は、陽性者の認証直後に削除することされている。
...
処理番号は、もっぱら認証目的で発行されるため、認証後ただちに破棄することに合理性がある。
以上より、本アプリでは、不要となったプライバシー情報は速やかに削除するものとされていると評価できる。

これらの評価報告はCOCOAの仕様書に対して実施されているため、COCOAの実装が仕様書通りであればプライバシーに最大限配慮しているということになります。

しかし、COCOAの実装を参照すると仕様書通りではない箇所が見られます。

仕様書に記載のない識別子を使用している

COCOAでは仕様書に記載のない2つの識別子を使用しています。
これはCOCOAリリース初期に話題になり、GithubのIssueにも登録されています。

#514 userUuid および secret の廃止
https://github.com/Covid-19Radar/Covid19Radar/issues/514

UserUuidはアプリ起動後、チュートリアルで利用規約に同意した時点で通知サーバー上で作成される無意な乱数値で、アプリの内部に保存されます。陽性者として登録する際に通知サーバーに送信され、AzureのCosomosDB上に処理番号(SubmissionNumber)、診断キー(Keys)と紐づいた状態で保存されます。

public async Task<DiagnosisModel> SubmitDiagnosisAsync(string SubmissionNumber, DateTimeOffset timestamp, string UserUuid, TemporaryExposureKeyModel[] Keys)  
{  
    _logger.LogInformation($"start {nameof(SubmitDiagnosisAsync)}");  
    var item = new DiagnosisModel()  
    {  
        id = UserUuid,  
        UserUuid = UserUuid,  
        SubmissionNumber = SubmissionNumber,  
        Approved = false,  
        Timestamp = timestamp.ToUnixTimeSeconds(),  
        Keys = Keys  
    };  

    return (await _db.Diagnosis.UpsertItemAsync<DiagnosisModel>(item)).Resource;  
}  

CosmosDiagnosisRepository.cs

評価報告書によると診断キーについて「個人情報である処理番号を紐づけることによって、診断キーから特定の個人を識別することができる場合には」要配慮個人情報にあたると評価されています。同じ基準にあてはめると、UserUuidについても診断キーと同様に処理番号に紐づけられているため、要配慮個人情報に該当する可能性があります。

処理番号の削除タイミング

評価報告書では以下のような記載があります。

処理番号は、もっぱら認証目的で発行されるため、認証後ただちに破棄することに合理性がある。

しかし、この記述が参照している仕様書の第1編7では、処理番号の削除タイミングについては以下のような記述になっています。


処理番号 - 削除タイミング: 端末の本人確認の終了時(端末)

日次キー、接触符号の記載と比較すると、「端末の本人確認の終了時(端末)」というのは端末側での削除タイミングを示したものであり、必ずしも通知サーバー側の削除タイミングを示したものではないようにも読み取れます。(*2)

仕様と評価のズレは気になりますが、処理番号については「認証後ただちに破棄する」ことが合理的であるという評価は確定しているため、通知サーバーの実装がどのようになっているかを確認します。処理番号(VerificationPayload)を元に本人確認を実施しているのは以下の箇所になります。

// validatetion VerificationPayload  
var verificationResult = await VerificationService.VerificationAsync(diagnosis.VerificationPayload);  
if (verificationResult != 200)  
{  
    return new ObjectResult("Bad VerificationPayload") { StatusCode = verificationResult };  
}  

DiagnosisAPI.cs

評価報告書に従えば、この後に処理番号が削除されるべきですが、実装上はそのようになっていません。この後に先ほどの処理番号、日次キー、UserUuidを紐づける処理が行われています。

公開されているコード上からは他の識別子と紐づけられた処理番号が削除されるタイミングは明確ではないのですが、以下のオプトアウト機能に関するコードに削除の痕跡が見られます。

// delete tek  
await DiagnosisRepository.DeleteAsync(user);  

OptOutApi.cs

そもそもCovid19Radarプロジェクトは当初からオプトアウト機能の導入を想定しており、処理番号を含むデータについて本人確認後に即時削除する想定をしていないであろうことはIssueにあった開発者コメントからもうかがえます。

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

評価報告書では「処理番号は、もっぱら認証目的で発行されるため、認証後ただちに破棄することに合理性がある」と記載されているため、現状の実装はプライバシーの観点からは合理性がないことになります。

*1 この記事においてはCOCOAの実装 = Covid19Radarの実装としています。今回記載した範囲においては両者の実装上の違いは存在していないものと思われます。

*2 評価報告書では全般において「処理番号は認証終了後に通知サーバーから削除する」と認識しているようなので、有識者会において誤った認識のもとで評価が実施された可能性もあります。

技術ブログをはじめよう Qrunch(クランチ)は、プログラマの技術アプトプットに特化したブログサービスです
駆け出しエンジニアからエキスパートまで全ての方々のアウトプットを歓迎しております!
or 外部アカウントで 登録 / ログイン する
クランチについてもっと詳しく

この記事が掲載されているブログ

⭐オススメ技術ブログ⭐

よく一緒に読まれる記事

0件のコメント

ブログ開設 or ログイン してコメントを送ってみよう