You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
An adversary with full knowledge of all EphIDs sent and received by each device would have a complete picture of all interactions. It is critical to ensure that neither Apple nor Google receive EphIDs in their cloud backups.
Here are some constructive comments in this regard:
This seems an important point to mention in the Detailed Stage-by-Stage Analysis section of the Data Protection and Security document. I can help with the writing if deemed appropriate.
For the iOS keychain in DP3TSDK/Database/Keychain.swift, kSecAttrAccessible is set to kSecAttrAccessibleAfterFirstUnlock, which allows for cloud backups of EphIDs (albeit encypted, with what could be a low or medium entropy password). It seems that it may be better to set it to kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly.
The HandshakesStorage and LoggingStorage classes (this last one only in log messages produced in CALIBRATION mode) may be storing EphIDs in an SQLite database that would backed up in the cloud. Perhaps all application data should be excluded from backups by setting NSURLIsExcludedFromBackupKey as described in https://developer.apple.com/library/archive/qa/qa1719/_index.html.
For the android version, there are some backup exclusions in dp3t_sdk_backup_rules.xml, but perhaps it may be better to completely disable backups with <application android:allowBackup="false" ... > in the manifest file (or to employ path=".", if for some reason that is not desirable). This would prevent any information leak due to missed data files (e.g., due to a change in storage location and a forgotten backup exclusion rule).
The text was updated successfully, but these errors were encountered:
simonroesch
added
the
prestandard
This issue is referring to the "prestandard" solution and not the current GAEN implementation.
label
May 19, 2020
An adversary with full knowledge of all EphIDs sent and received by each device would have a complete picture of all interactions. It is critical to ensure that neither Apple nor Google receive EphIDs in their cloud backups.
Here are some constructive comments in this regard:
This seems an important point to mention in the Detailed Stage-by-Stage Analysis section of the Data Protection and Security document. I can help with the writing if deemed appropriate.
For the iOS keychain in
DP3TSDK/Database/Keychain.swift
,kSecAttrAccessible
is set tokSecAttrAccessibleAfterFirstUnlock
, which allows for cloud backups of EphIDs (albeit encypted, with what could be a low or medium entropy password). It seems that it may be better to set it tokSecAttrAccessibleAfterFirstUnlockThisDeviceOnly
.The
HandshakesStorage
andLoggingStorage
classes (this last one only in log messages produced inCALIBRATION
mode) may be storing EphIDs in an SQLite database that would backed up in the cloud. Perhaps all application data should be excluded from backups by settingNSURLIsExcludedFromBackupKey
as described inhttps://developer.apple.com/library/archive/qa/qa1719/_index.html
.For the android version, there are some backup exclusions in
dp3t_sdk_backup_rules.xml
, but perhaps it may be better to completely disable backups with<application android:allowBackup="false" ... >
in the manifest file (or to employpath="."
, if for some reason that is not desirable). This would prevent any information leak due to missed data files (e.g., due to a change in storage location and a forgotten backup exclusion rule).The text was updated successfully, but these errors were encountered: