Re: Efficient test for weak RSA keys generated in Infineon TPMs / smartcards

[Matt Palmer via dev-security-policy]

On Mon, Oct 16, 2017 at 09:14:29PM +0100, Rob Stradling via dev-security-policy 
wrote:
> On 16/10/17 20:01, Matthew Hardeman via dev-security-policy wrote:
> > The authors of the paper on the weak RSA keys generated by Infineon TPMs 
> > and smart cards have published code in multiple languages / platforms that 
> > provide for an efficient test for weakness by way of the Infineon TPM bug.
> > 
> > Perhaps this should be a category of issue identified by the crt.sh engine, 
> > etc?
> 
> Hi Matt.  Yeah, I'm working on adding the ROCA check to crt.sh.

Whoops, didn't see this before I submitted
https://github.com/awslabs/certlint/pull/55.

- Matt

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Efficient test for weak RSA keys generated in Infineon TPMs / smartcards

[Jakob Bohm via dev-security-policy]

On 16/10/2017 21:01, Matthew Hardeman wrote:

The authors of the paper on the weak RSA keys generated by Infineon TPMs and 
smart cards have published code in multiple languages / platforms that provide 
for an efficient test for weakness by way of the Infineon TPM bug.

Perhaps this should be a category of issue identified by the crt.sh engine, etc?

Should someone put together a ballot for incorporating this category of weak 
keys as a mandatory check before issuing certs?

Code for testing keys is at: https://github.com/crocs-muni/roca

It looks like the test is exceptionally easy math against the modulus of the 
public key.

Thanks,

Matt Hardeman



Unfortunately, as of right now, their github repository still doesn't
include the promised C/C++ implementation, and their Python
implementation requires a fairly new Python version (with details
inconsistent between README.md and a quick look at setup.py).

They have also obfuscated their test by providing bitmasks as decimal
bigints instead of using hexadecimal or any other format that makes the
bitmasks human readable.

But if you happen to run a new enough environment, their tests may at
least be runable, and you may be able to deobfuscate the bitmasks with
your favorite bignum calculator.


Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: SSL.com root inclusion request

[Kathleen Wilson via dev-security-policy]

Thank you to those of you who reviewed and commented on this request from 
SSL.com to include the “SSL.com Root Certification Authority RSA”, “SSL.com 
Root Certification Authority ECC”, “SSL.com EV Root Certification Authority RSA 
R2”, and “SSL.com EV Root Certification Authority ECC” root certificates, turn 
on the Email and Websites trust bits for the two non-EV roots, turn on the 
Websites trust bit for the two EV roots, and enable EV treatment for the two EV 
roots. 

I believe that all of the questions and concerns that were raised in this 
discussion have been properly addressed.

As a result of this discussion, there are a couple of minor changes that the CA 
plans to make in their CP/CPS, but those are not show-stoppers.

Therefore, I am closing this discussion and I will state my intent to approve 
this request in the bug.

https://bugzilla.mozilla.org/show_bug.cgi?id=1277336

Any further follow-up should be added directly to the bug.

Thanks,
Kathleen
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Efficient test for weak RSA keys generated in Infineon TPMs / smartcards

[Rob Stradling via dev-security-policy]

On 16/10/17 20:01, Matthew Hardeman via dev-security-policy wrote:

The authors of the paper on the weak RSA keys generated by Infineon TPMs and 
smart cards have published code in multiple languages / platforms that provide 
for an efficient test for weakness by way of the Infineon TPM bug.

Perhaps this should be a category of issue identified by the crt.sh engine, etc?


Hi Matt.  Yeah, I'm working on adding the ROCA check to crt.sh.


Should someone put together a ballot for incorporating this category of weak 
keys as a mandatory check before issuing certs?
 
Code for testing keys is at: https://github.com/crocs-muni/roca


It looks like the test is exceptionally easy math against the modulus of the 
public key.


--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Mozilla’s Plan for Symantec Roots

[Peter Bowen via dev-security-policy]

On Mon, Oct 16, 2017 at 10:32 AM, Gervase Markham via
dev-security-policy  wrote:
> As per previous discussions and
> https://wiki.mozilla.org/CA:Symantec_Issues, a consensus proposal[0] was
> reached among multiple browser makers for a graduated distrust of
> Symantec roots.
>
> Here is Mozilla’s planned timeline for the graduated distrust of
> Symantec roots (subject to change):
>
> * October 2018 (Firefox 63): Removal/distrust of Symantec roots, with
> caveats described below.
>
> However, there are some subCAs of the Symantec roots that are
> independently operated by companies whose operations have not been
> called into question, and they will experience significant hardship if
> we do not provide a longer transition period for them. For both
> technical and non-technical reasons, a year is an extremely unrealistic
> timeframe for these subCAs to transition to having their certificates
> cross-signed by another CA. For example, the subCA may have implemented
> a host of pinning solutions in their products that would fail with
> non-Symantec-chaining certificates, or the subCA may have large numbers
> of devices that would need to be tested for interoperability with any
> potential future vendor. And, of course contractual negotiations may
> take a significant amount of time.

This pattern also exists for companies that have endpoints which have
clients which are pinned to the Symantec-owned roots.  These endpoints
may also be used by browser clients. It was my understanding that the
intent was existing roots would cross sign new managed CAs that would
be used for transition.

> Add code to Firefox to disable the root such that only certain subCAs
> will continue to function. So, the final dis-trust of Symantec roots may
> actually involve letting one or two of the root certs remain in
> Mozilla’s trust store, but having special code to distrust all but
> specified subCAs. We would document the information here:
> https://wiki.mozilla.org/CA/Additional_Trust_Changes
> And Mozilla would add tooling to the CCADB to track these special subCAs
> to ensure proper CP/CPS/audits until they have been migrated and
> disabled, and the root certs removed. Mozilla will need to also follow
> up with these subCAs to ensure they are moving away from these root
> certificates and are getting cross-signed by more than one CA in order
> to avoid repeating this situation.

Will the new managed CAs, which will operated by DigiCert under
CP/CPS/Audit independent from the current Symantec ones, also be
included on the list of subCAs that will continue to function?

Thanks,
Peter
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Mozilla’s Plan for Symantec Roots

[Daniel Cater via dev-security-policy]

On Monday, 16 October 2017 18:32:54 UTC+1, Gervase Markham  wrote:
> = Symantec roots to be disabled via code, *not* removed from NSS =
> 
> GeoTrust Global CA
> GeoTrust Primary Certification Authority - G2
> GeoTrust Primary Certification Authority - G3
> 
> = Symantec roots that will be fully removed from NSS =
> 
> GeoTrust Primary Certification Authority
> GeoTrust Universal CA
> GeoTrust Universal CA 2
> Symantec Class 1 Public Primary Certification Authority - G4
> Symantec Class 1 Public Primary Certification Authority - G6
> Symantec Class 2 Public Primary Certification Authority - G4
> Symantec Class 2 Public Primary Certification Authority - G6
> thawte Primary Root CA
> thawte Primary Root CA - G2
> thawte Primary Root CA - G3
> VeriSign Class 1 Public PCA - G3
> VeriSign Class 2 Public PCA - G3
> VeriSign Class 3 Public Primary Certification Authority - G3
> VeriSign Class 3 Public Primary Certification Authority - G4
> VeriSign Class 3 Public Primary Certification Authority - G5
> VeriSign Universal Root Certification Authority

Could we have a list of the subCAs that are being considered for exemption for 
the distrust?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Mozilla’s Plan for Symantec Roots

[Eric Mill via dev-security-policy]

Adding code to Firefox to support the distrust of specified subCAs seems
like it would be a good long-term investment for Mozilla, as it would give
Mozilla a lot more flexibility during future distrust events.

-- Eric

On Mon, Oct 16, 2017 at 1:32 PM, Gervase Markham via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> As per previous discussions and
> https://wiki.mozilla.org/CA:Symantec_Issues, a consensus proposal[0] was
> reached among multiple browser makers for a graduated distrust of
> Symantec roots.
>
> Here is Mozilla’s planned timeline for the graduated distrust of
> Symantec roots (subject to change):
>
> * January 2018 (Firefox 58): Notices in the Developer Console will warn
> about Symantec certificates issued before 2016-06-01, to encourage site
> owners to migrate their TLS certs.
>
> * May 2018 (Firefox 60): Websites will show an untrusted connection
> error if they have a TLS cert issued before 2016-06-01 that chains up to
> a Symantec root.
>
> * October 2018 (Firefox 63): Removal/distrust of Symantec roots, with
> caveats described below.
>
> Mozilla’s release calendar is here:
> https://wiki.mozilla.org/RapidRelease/Calendar
>
> However, there are some subCAs of the Symantec roots that are
> independently operated by companies whose operations have not been
> called into question, and they will experience significant hardship if
> we do not provide a longer transition period for them. For both
> technical and non-technical reasons, a year is an extremely unrealistic
> timeframe for these subCAs to transition to having their certificates
> cross-signed by another CA. For example, the subCA may have implemented
> a host of pinning solutions in their products that would fail with
> non-Symantec-chaining certificates, or the subCA may have large numbers
> of devices that would need to be tested for interoperability with any
> potential future vendor. And, of course contractual negotiations may
> take a significant amount of time.
>
> The subCAs that we know of that fall into this category belong to Google
> and Apple. If there are any other subCAs that fall into this category,
> please let us know immediately. Google has one such subCA; Apple has seven.
>
> There are two ways that we can provide a smoother transition for these
> subCAs.
>
> Option 1)
> Temporarily treat these subCAs as directly-included trust-anchors.
> Mozilla prefers *not* to take this approach, because even if clearly
> explained up front that it is a temporary solution with deadlines, it
> would be very easy for people to start treating such a subCA as a
> regular trust anchor, and thereby have that subCA become a de facto
> included CA. Additionally, it could become very complicated to remove
> such subCAs in the future, especially if they have not performed the
> recommended transitions.
>
> Option 2)
> Add code to Firefox to disable the root such that only certain subCAs
> will continue to function. So, the final dis-trust of Symantec roots may
> actually involve letting one or two of the root certs remain in
> Mozilla’s trust store, but having special code to distrust all but
> specified subCAs. We would document the information here:
> https://wiki.mozilla.org/CA/Additional_Trust_Changes
> And Mozilla would add tooling to the CCADB to track these special subCAs
> to ensure proper CP/CPS/audits until they have been migrated and
> disabled, and the root certs removed. Mozilla will need to also follow
> up with these subCAs to ensure they are moving away from these root
> certificates and are getting cross-signed by more than one CA in order
> to avoid repeating this situation.
>
> According to option 2 and the plan listed above, here is how the
> currently-included Symantec root certs will be treated in Firefox 63:
>
> = Symantec roots to be disabled via code, *not* removed from NSS =
>
> GeoTrust Global CA
> GeoTrust Primary Certification Authority - G2
> GeoTrust Primary Certification Authority - G3
>
> = Symantec roots that will be fully removed from NSS =
>
> GeoTrust Primary Certification Authority
> GeoTrust Universal CA
> GeoTrust Universal CA 2
> Symantec Class 1 Public Primary Certification Authority - G4
> Symantec Class 1 Public Primary Certification Authority - G6
> Symantec Class 2 Public Primary Certification Authority - G4
> Symantec Class 2 Public Primary Certification Authority - G6
> thawte Primary Root CA
> thawte Primary Root CA - G2
> thawte Primary Root CA - G3
> VeriSign Class 1 Public PCA - G3
> VeriSign Class 2 Public PCA - G3
> VeriSign Class 3 Public Primary Certification Authority - G3
> VeriSign Class 3 Public Primary Certification Authority - G4
> VeriSign Class 3 Public Primary Certification Authority - G5
> VeriSign Universal Root Certification Authority
>
> As always, we appreciate your thoughtful and constructive feedback on this.
>
> Gerv
>
> [0]
> https://groups.google.com/a/chromium.org/forum/#!topic/
> blink-dev/eUAKwjihhBs%5B251-275%5D
> 

Mozilla’s Plan for Symantec Roots

[Gervase Markham via dev-security-policy]

As per previous discussions and
https://wiki.mozilla.org/CA:Symantec_Issues, a consensus proposal[0] was
reached among multiple browser makers for a graduated distrust of
Symantec roots.

Here is Mozilla’s planned timeline for the graduated distrust of
Symantec roots (subject to change):

* January 2018 (Firefox 58): Notices in the Developer Console will warn
about Symantec certificates issued before 2016-06-01, to encourage site
owners to migrate their TLS certs.

* May 2018 (Firefox 60): Websites will show an untrusted connection
error if they have a TLS cert issued before 2016-06-01 that chains up to
a Symantec root.

* October 2018 (Firefox 63): Removal/distrust of Symantec roots, with
caveats described below.

Mozilla’s release calendar is here:
https://wiki.mozilla.org/RapidRelease/Calendar

However, there are some subCAs of the Symantec roots that are
independently operated by companies whose operations have not been
called into question, and they will experience significant hardship if
we do not provide a longer transition period for them. For both
technical and non-technical reasons, a year is an extremely unrealistic
timeframe for these subCAs to transition to having their certificates
cross-signed by another CA. For example, the subCA may have implemented
a host of pinning solutions in their products that would fail with
non-Symantec-chaining certificates, or the subCA may have large numbers
of devices that would need to be tested for interoperability with any
potential future vendor. And, of course contractual negotiations may
take a significant amount of time.

The subCAs that we know of that fall into this category belong to Google
and Apple. If there are any other subCAs that fall into this category,
please let us know immediately. Google has one such subCA; Apple has seven.

There are two ways that we can provide a smoother transition for these
subCAs.

Option 1)
Temporarily treat these subCAs as directly-included trust-anchors.
Mozilla prefers *not* to take this approach, because even if clearly
explained up front that it is a temporary solution with deadlines, it
would be very easy for people to start treating such a subCA as a
regular trust anchor, and thereby have that subCA become a de facto
included CA. Additionally, it could become very complicated to remove
such subCAs in the future, especially if they have not performed the
recommended transitions.

Option 2)
Add code to Firefox to disable the root such that only certain subCAs
will continue to function. So, the final dis-trust of Symantec roots may
actually involve letting one or two of the root certs remain in
Mozilla’s trust store, but having special code to distrust all but
specified subCAs. We would document the information here:
https://wiki.mozilla.org/CA/Additional_Trust_Changes
And Mozilla would add tooling to the CCADB to track these special subCAs
to ensure proper CP/CPS/audits until they have been migrated and
disabled, and the root certs removed. Mozilla will need to also follow
up with these subCAs to ensure they are moving away from these root
certificates and are getting cross-signed by more than one CA in order
to avoid repeating this situation.

According to option 2 and the plan listed above, here is how the
currently-included Symantec root certs will be treated in Firefox 63:

= Symantec roots to be disabled via code, *not* removed from NSS =

GeoTrust Global CA
GeoTrust Primary Certification Authority - G2
GeoTrust Primary Certification Authority - G3

= Symantec roots that will be fully removed from NSS =

GeoTrust Primary Certification Authority
GeoTrust Universal CA
GeoTrust Universal CA 2
Symantec Class 1 Public Primary Certification Authority - G4
Symantec Class 1 Public Primary Certification Authority - G6
Symantec Class 2 Public Primary Certification Authority - G4
Symantec Class 2 Public Primary Certification Authority - G6
thawte Primary Root CA
thawte Primary Root CA - G2
thawte Primary Root CA - G3
VeriSign Class 1 Public PCA - G3
VeriSign Class 2 Public PCA - G3
VeriSign Class 3 Public Primary Certification Authority - G3
VeriSign Class 3 Public Primary Certification Authority - G4
VeriSign Class 3 Public Primary Certification Authority - G5
VeriSign Universal Root Certification Authority

As always, we appreciate your thoughtful and constructive feedback on this.

Gerv

[0]
https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/eUAKwjihhBs%5B251-275%5D

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Mozilla’s Plan for Symantec Roots

[Gervase Markham via dev-security-policy]

As per previous discussions and
https://wiki.mozilla.org/CA:Symantec_Issues, a consensus proposal[0] was
reached among multiple browser makers for a graduated distrust of
Symantec roots.

Here is Mozilla’s planned timeline for the graduated distrust of
Symantec roots (subject to change):

* January 2018 (Firefox 58): Notices in the Developer Console will warn
about Symantec certificates issued before 2016-06-01, to encourage site
owners to migrate their TLS certs.

* May 2018 (Firefox 60): Websites will show an untrusted connection
error if they have a TLS cert issued before 2016-06-01 that chains up to
a Symantec root.

* October 2018 (Firefox 63): Removal/distrust of Symantec roots, with
caveats described below.

Mozilla’s release calendar is here:
https://wiki.mozilla.org/RapidRelease/Calendar

However, there are some subCAs of the Symantec roots that are
independently operated by companies whose operations have not been
called into question, and they will experience significant hardship if
we do not provide a longer transition period for them. For both
technical and non-technical reasons, a year is an extremely unrealistic
timeframe for these subCAs to transition to having their certificates
cross-signed by another CA. For example, the subCA may have implemented
a host of pinning solutions in their products that would fail with
non-Symantec-chaining certificates, or the subCA may have large numbers
of devices that would need to be tested for interoperability with any
potential future vendor. And, of course contractual negotiations may
take a significant amount of time.

The subCAs that we know of that fall into this category belong to Google
and Apple. If there are any other subCAs that fall into this category,
please let us know immediately. Google has one such subCA; Apple has seven.

There are two ways that we can provide a smoother transition for these
subCAs.

Option 1)
Temporarily treat these subCAs as directly-included trust-anchors.
Mozilla prefers *not* to take this approach, because even if clearly
explained up front that it is a temporary solution with deadlines, it
would be very easy for people to start treating such a subCA as a
regular trust anchor, and thereby have that subCA become a de facto
included CA. Additionally, it could become very complicated to remove
such subCAs in the future, especially if they have not performed the
recommended transitions.

Option 2)
Add code to Firefox to disable the root such that only certain subCAs
will continue to function. So, the final dis-trust of Symantec roots may
actually involve letting one or two of the root certs remain in
Mozilla’s trust store, but having special code to distrust all but
specified subCAs. We would document the information here:
https://wiki.mozilla.org/CA/Additional_Trust_Changes
And Mozilla would add tooling to the CCADB to track these special subCAs
to ensure proper CP/CPS/audits until they have been migrated and
disabled, and the root certs removed. Mozilla will need to also follow
up with these subCAs to ensure they are moving away from these root
certificates and are getting cross-signed by more than one CA in order
to avoid repeating this situation.

According to option 2 and the plan listed above, here is how the
currently-included Symantec root certs will be treated in Firefox 63:

= Symantec roots to be disabled via code, *not* removed from NSS =

GeoTrust Global CA
GeoTrust Primary Certification Authority - G2
GeoTrust Primary Certification Authority - G3

= Symantec roots that will be fully removed from NSS =

GeoTrust Primary Certification Authority
GeoTrust Universal CA
GeoTrust Universal CA 2
Symantec Class 1 Public Primary Certification Authority - G4
Symantec Class 1 Public Primary Certification Authority - G6
Symantec Class 2 Public Primary Certification Authority - G4
Symantec Class 2 Public Primary Certification Authority - G6
thawte Primary Root CA
thawte Primary Root CA - G2
thawte Primary Root CA - G3
VeriSign Class 1 Public PCA - G3
VeriSign Class 2 Public PCA - G3
VeriSign Class 3 Public Primary Certification Authority - G3
VeriSign Class 3 Public Primary Certification Authority - G4
VeriSign Class 3 Public Primary Certification Authority - G5
VeriSign Universal Root Certification Authority

As always, we appreciate your thoughtful and constructive feedback on this.

Gerv

[0]
https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/eUAKwjihhBs%5B251-275%5D
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RSA key generation vulnerability in Infineon firmware

[Alex Gaynor via dev-security-policy]

Hi all,

Today researchers announced a vulnerability they discovered in RSA keys
generated by a particular piece of firmware, which allows practical
factorization of the private key given just the public key.

Full details of the research here:
https://crocs.fi.muni.cz/public/papers/rsa_ccs17

There is a publicly available tool for testing keys here:
https://github.com/crocs-muni/roca

I'd encourage CAs to proactive check all of their issued certificates,
particularly S/MIME/client certs, since this affects common smartcard
implementations.

Cheers,
Alex
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy