Incident Report D-Trust certificates with ROCA Fingerprints Kim Nguyen, D-Trust, 2017.11.03
1 How your CA first became aware of the problem (e.g. via a problem report submitted to your Problem Reporting Mechanism, a discussion in mozilla.dev.security.policy, a Bugzilla bug, or internal self-audit), and the time and date. On 2017/10/16 the initial version of the public disclosure was published on https://crocs.fi.muni.cz/public/papers/rsa_ccs17. A list of certificates showing a ROCA fingerprint was posted by Rob Stradling at Mozilla.dev.security.policy on 2017/10/18 available at https://misissued.com/batch/28/ This contains among other certificates a number of D-Trust related certificates that all show a ROCA fingerprint. 2 A timeline of the actions your CA took in response. A timeline is a date-and-time-stamped sequence of all relevant events. This may include events before the incident was reported, such as when a particular requirement became applicable, or a document changed, or a bug was introduced, or an audit was done. 2017/10/18 D-TRUST set up a team to evaluate the incident. 2017/10/19 the result was published. The eIDAS regulation became mandatory at the 1st of July 2017. Therefore all certificates related to D-Trust at https://misissued.com/batch/28/ where deactivated during June 2017 and revoked later in order to comply with the new eIDAS requirements which include an eIDAS conformity assessment as well as various technical adaptions. The Status of the related Services can be inspected on the German TSL. 3 Whether your CA has stopped, or has not yet stopped, issuing certificates with the problem. A statement that you have will be considered a pledge to the community; a statement that you have not requires an explanation. All certificates related to D-Trust at https://misissued.com/batch/28/ where deactivated during June 2017 and revoked later. All of these certificates are not related to WebPKI, i.e. are not chaining to a root trusted by NSS. 4 A summary of the problematic certificates. For each problem: number of certs, and the date the first and last certs with that problem were issued. Please see at https://misissued.com/batch/28 5 The complete certificate data for the problematic certificates. The recommended way to provide this is to ensure each certificate is logged to CT and then list the fingerprints or crt.sh IDs, either in the report or as an attached spreadsheet, with one list per distinct problem. Please see at https://misissued.com/batch/28 6 Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now. Please see https://www.infineon.com/cms/en/product/promopages/rsa-update/rsa-background The rootcause of ROCA as well known is a Problem with the RSA key Generation as implemented in SW on certain IFX components. 7 List of steps your CA is taking to resolve the situation and ensure such issuance will not be repeated in the future, accompanied with a timeline of when your CA expects to accomplish these things. All qualified Services are now HSM based as allowed now via the EU eIDAS Regulation. Therefore no smart Card based components are any longer used internally by D-Trust. Furthermore we have set up Systems to Screen for the ROCA vulnerability. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
