8/22タイムスタンプの接触日2027年の問題

[moonmile]

鈴木さんのツイートから https://twitter.com/info_kvaluation/status/1302992824745435141

今夜も接触日シートを更新しましたよ。 8/22タイムスタンプの接触日2027年の5件、消えなそう。

初期データ？の接触日がおかしい関係で「2027年」のが残るらしいです。 多分、サーバー側のデータ修正でクリアできると思うのですが、いったんここで軽く調査してみて、厚生労働省の issues へ。

[kvaluation]

ダミー2027の特定

Fig.1

削除されずに通知サーバーに残っていて、毎日配信されているzipファイル（ダミー2027という）は、下記５件。

865　接触日2027/8/25 866　接触日2027/8/24 867　接触日2027/8/23 868　接触日2027/8/22 869　接触日2027/8/21

Fig.1は、TEKを整理しているシートである rocazさんの　probeCOCOATek を使ってダウンロードしたものを私がGoogle Spreadsheetに読み込んでいる（非公開）。 （ダミー2027の5件でstart_timestampがNAになっているのは、正規表現で2020年のものだけ読み出しているため）

ダミー2027は、rolling_start_interval_numberが 3031920 などとなっており、日に戻すと2027/8/25となる。 rolling_start_interval_numberはTEKがRPIsを生み出し始めた日時であり、従って、接触日の開始時刻である。

接触日が将来の日付けのTEKを含んだことは、u_akihiroさんやSumoMannedさんも気づいて当日にTwitteしてくれてた記憶。 https://twitter.com/u_akihiro https://twitter.com/SumoManned

ダミー2027の受信開始

Fig.2,3は鈴木が公開している接触日シートのダミー2027部分である。 https://docs.google.com/spreadsheets/d/16ZrHDBJXTgg0eKfIQbr-d4BwkgTbV4-5MG6BcyU7d_Q/edit?usp=sharing

Fig.2

Fig.2（リスト8/22受信分のスクショ）を参照すると、8/22タイムスタンプで、zip番号865から869のダミー2027の5件がTEKに含まれた。

なお、この接触日シートは、接触日を知りたい方が閲覧するため、ダミー受信当初から「←このzipで一致はエラーなのでご連絡ください」と記載しておいたが、このzipで一致したケースは発見できなかった。

8/22タイムスタンプのzipの接触日は、8/8-8/20の13件と、ダミー2027の5件の合計18件であった。

この接触日シートでは、zip番号の小さい方が上部にくるため、日の経過とともにダミー2027の5件は上部に移動した。

ダミー2027の現在（9/9）

Fig.3

リスト0908受信分では、8/22配信開始（タイムスタンプ）の正常なzipはすべて削除（又は、通知対象から外されて）おり、配信対象となっていない。8/23配信開始と8/24配信開始分もすでに削除されている。

8/25配信分では、接触日が8/23の1件のみが残り、接触日が8/22のものは、9/8付けでは削除されている。

現在、接触日が17日前のzipが削除されるのが通例となっている。

ダミー2027の将来と、提案

現在の運用では、接触日で削除対象のzipを特定している。（zip単位で削除できるように、同一zipには同一の接触日のTEKを集めている）

すると、ダミー2027の5件は、2027年の8月まで削除されないこととなる。

特段の不具合を直接に発生させてはいない（※）が、接触確認の照合に無関係なzipファイルを全端末に毎晩送信するのは不必要であり、手動で削除するか、接触日が将来のzipは配信対象から除くことが望まれる。

※8/22タイムスタンプの他の13件は、接触日シートでのご相談者で心当たりのある接触日だとおっしゃる方が数名おり、接触日を正常に照合できていたものと思われる。

[kvaluation]

受信済みのzipを再度受信しない差分通信が実装されているならば、全端末に毎晩送信されることはない、という可能性に気づきました。 この点含め、コードの精査はしておりません。

[moonmile]

詳細データをありがとうございます。

サーバーで zip に固めている部分が以下の場所です。

https://github.com/cocoa-mhlw/cocoa/blob/master/src/Covid19Radar.Background/Services/TemporaryExposureKeyExportBatchService.cs#L71

foreach (var kv in items.GroupBy(_ => new
{
    RollingStartUnixTimeSeconds = _.GetRollingStartUnixTimeSeconds(),
    RollingPeriodSeconds = _.GetRollingPeriodSeconds()
}))
{

• RollingStartUnixTimeSeconds（接触日）
• RollingPeriodSeconds （これは現状 144 固定で 24時間単位）

日単位で zip をまとめているので仕組み上、新しい陽性者登録があった場合に過去の zip の中身も変わるので zip の更新日を変更。 この時、ダウンロードするときに、

https://github.com/cocoa-mhlw/cocoa/blob/master/Covid19Radar/Covid19Radar/Services/ExposureNotificationHandler.cs#L149

foreach (var tekItem in tekList)
{
    long lastCreated = 0;
    if (lastTekTimestamp.ContainsKey(region))
    {
        lastCreated = lastTekTimestamp[region];
    }
    else
    {
        lastTekTimestamp.Add(region, 0);
    }

    if (tekItem.Created > lastCreated || lastCreated == 0) // ※ここで比較
    {
        var tmpFile = Path.Combine(tmpDir, Guid.NewGuid().ToString() + ".zip");
        Debug.WriteLine(Utils.SerializeToJson(tekItem));
        Debug.WriteLine(tmpFile);

で、更新日（Created）を比較しながらダウンロードしています。

このため、2027年の zip は、更新されないので、ダウンロードから省かれます。 結論としては、list.json には入っているけどダウンロードはしなさそうです。

[kvaluation]

対応コードをありがとうございます。

2027年zipは、

• list.json から消えない。
• 1回はダウンロードしている。
• 更新日（Created）を比較によりダウンロードは1回のみ。

と理解してみました。

いま、ダウンロードは、OS側で自動的に毎日ダウンロードするのと、 アプリ立ち上げ時にダウンロードするのと少なくとも２通りありますが、

OSもこの示して頂いたコードを使っているのか、そこまでは現状、調査できてません。

[kvaluation]

Temporary Exposure Key (TEK) Publishing Guide https://github.com/google/exposure-notifications-server/blob/main/docs/getting-started/publishing-temporary-exposure-keys.md#server-access-configuration

Keys with a future start time (rollingStartNumber indicates time > now), are rejected.

とあるので、ダミー2027は、想定外の動作をもたらしてしまう可能性もあるかと考えるに至りました。

とりあえず9/11午前中に厚生労働省窓口にメールしておこうかと思います。

[kvaluation]

list.jsonのデータとコード

list.jsonのURL https://covid19radar-jpn-prod.azureedge.net/c19r/440/list.json

probeCOCOATek による　list.json　の中身

`

Created ZIP URL Keys Count

1 [2020-08-22 00:00:37+0900] [https://covid19radar-jpn-prod.azureedge.net/c19r/440/865.zip ] [ 1] `

Batch番号=zip番号

https://github.com/cocoa-mhlw/cocoa/blob/97e042e444599fe44afbe8046118edd6f8daeab3/src/Covid19Radar.Background/Services/TemporaryExposureKeyBlobService.cs#L106

Url = $"{TekExportKeyUrl}/{TekExportBlobStorageContainerPrefix}/{region}/{_.BatchNum}.zip"

440:　region (日本) _.BatchNum: 865 (zip番号)

[kvaluation]

zipのデータとコード

865.zipの例

1. zip単位のデータ（probeCOCOATek による　export.bin　の中身）

start_timestamp: [2027-08-25 09:00:00+0900] end_timestamp: [2027-08-26 09:00:00+0900] region: [440] batch_num: [1] batch_size: [1] signature_infos: verification_key_version: [v1] verification_key_id: [440] signature_algorithm: [1.2.840.10045.4.3.2] Keys: (Count: [1])

2. コード

https://github.com/cocoa-mhlw/cocoa/blob/97e042e444599fe44afbe8046118edd6f8daeab3/src/Covid19Radar.Background/Services/TemporaryExposureKeyExportBatchService.cs#L117

L134- var exportModel = new TemporaryExposureKeyExportModel(); exportModel.id = batchNum.ToString(); exportModel.PartitionKey = region; exportModel.BatchNum = batchNum; exportModel.Region = region; exportModel.BatchSize = exportKeyModels.Length; exportModel.StartTimestamp = startTimestamp; exportModel.EndTimestamp = endTimestamp; exportModel.TimestampSecondsSinceEpoch = DateTimeOffset.UtcNow.ToUnixTimeMilliseconds(); exportModel = await TekExportRepository.CreateAsync(exportModel);

3. 対比

exportModel.StartTimestamp: 2027-08-25 09:00:00+0900 exportModel.EndTimestamp: 2027-08-26 09:00:00+0900 exportModel.BatchNum: 1 exportModel.Region: 440 exportModel.BatchSize: 1

と、zip番号単位では、項目に対応がみられる。しかし、コード側に冗長（重複）がありこのまま動作しているかどうか不明。

なお、signature_algorithm: 1.2.840.10045.4.3.2　は、Elliptic曲線の電子署名とSecure Hash Algorithm 256 (SHA256)を組み合わせた方式（algorithm）が使われていることを示す。

[kvaluation]

key単位のデータ

同様に、865.zipの例

1. zip のkey (TEK) 単位のデータ（probeCOCOATek による　export.bin　の中身）

2. コードは未特定

(1) L75-L93: rolling_start_interval_numberの値に関係したソートがされて、配列に入れられている? https://github.com/cocoa-mhlw/cocoa/blob/97e042e444599fe44afbe8046118edd6f8daeab3/src/Covid19Radar.Background/Services/TemporaryExposureKeyExportBatchService.cs#L75

(2) L145-153: keyごとに記録していそうだが、対応するデータ項目はzipには入っていなさそう。 https://github.com/cocoa-mhlw/cocoa/blob/97e042e444599fe44afbe8046118edd6f8daeab3/src/Covid19Radar.Background/Services/TemporaryExposureKeyExportBatchService.cs#L145

(3)このbach処理で、export.binにある transmission_risk_level の値がいつ、どう記録されているのか追えていない(日本で使っていないが)。

[kvaluation]

下記文言でメールしました。

---

接触日が未来のTEK (export.binを含むzipファイル)が削除されない件

厚生労働省　接触確認アプリCOCOAご担当者様

接触確認アプリの推進にご尽力頂きありがとうございます。

8月22日に配信された下記番号のzipファイルがいつまでも削除されず、list.jsonでファイルが示される状態となっております（最終確認2020年9月11日 深夜1:00ごろ）

zip番号　接触日 865　接触日2027/8/25 866　接触日2027/8/24 867　接触日2027/8/23 868　接触日2027/8/22 869　接触日2027/8/21

接触日が未来の日付となっているキー(TEK)は、リジェクトされるべきとのgoogleによるガイドもありますので、削除するか、list.jsonから除かれるようにするか、何らかのご対応が望ましいと思われます。

（参考） Temporary Exposure Key (TEK) Publishing Guide https://github.com/google/exposure-notifications-server/blob/main/docs/getting-started/publishing-temporary-exposure-keys.md#server-access-configuration

Keys with a future start time (rollingStartNumber indicates time > now), are rejected. （参考おわり）

どのコードを修正すべきというご提案ができるほどの分析はできておりませんが、現状を具体的に下記サイトにて公開で整理しましたので、必要に応じてご参照ください。 https://github.com/openCACAO/cocoa-issues/issues/27

以上です。

[kvaluation]

2020年9月14日 8時半ばごろ、接触確認アプリサポートセンター様からご返信がありました。

転載と二次利用を禁止したい旨の要望が記載されておりまして、その一方的なご要望への同意はしませんが、要約してここに記します。

ここからメール返信の要約

・開発チームに伝え、調査します。 ・不具合の原因がわかれば、アプリをアップデートしていきます。 ・しかし、具体的なアップデートの時期は未定ですのでお待ちいただきたいです。 ・ご迷惑をおかけしてすみません。 ・ご連絡ありがとうございました。

ここまで要約

通知サーバーの問題なので、アプリのアップデートでは解決しないと思いますが、開発チームにお伝えいただいたとのことで、ダミー2027については、当面現状を静観したいと思います。

接触確認アプリサポートセンター殿におかれましては、心温まる表現でのご返信を早々にいただき、ありがとうございました。

このコードを直すべきではないか、などの情報ありましたら、続けてください。