In a related vein, I was playing around some time ago with generating RSA keys that would contain "interesting" payloads in the modulus. An example with Windows bind shellcode in the modulus, which when included in a DER-encoded CSR, gets flagged by ClamAV: https://gist.github.com/CBonnell/699b2c01121e07440e1cf42d0210eba1.
>From a policy standpoint, the BRs already establish an obligation for CAs to reject certificate requests that contain keys that are known to be weak, compromised, or if there is "clear evidence" that the method of generation was "flawed" (section 6.1.1.3). My interpretation of "flawed" in that section is that there is some characteristic or other information conveyed within the key (or certificate request as a whole) that would provide clear evidence that the key is unsuitable for use. I don't think that there was clear evidence in the case of the certificate that was previously linked to indicate that the method of generation was flawed. It would be useful to understand if the key in question was generated using tooling that may be used for other keys so that similar weak keys can be blocked (assuming that there is some shared trait in the public key that can be flagged). Thanks, Corey -----Original Message----- From: [email protected] <[email protected]> On Behalf Of Hanno Böck Sent: Saturday, December 3, 2022 2:49 PM To: [email protected] Subject: key with suspicious pattern Hi, I'm not entirely sure if this is the right place to discuss this, but I also don't really know where else. Do people have thoughts about suspicious keys like this? https://crt.sh/?id=8093628131 (Have a look at the modulus / N value, it has a lot of zeros) This key is certainly not securely generated. What I am wondering: * What caused such a key to be created? * Can it be broken? * Anyone aware of any analysis or relevant research for keys with suspicious patterns? * Should CAs be under any obligation to detect and reject such keys? (I am detecting such keys in badkeys by looking for 16 repeating bytes, which I consider as practically impossible to happen by chance in a proper key generation process.) -- Hanno Böck https://hboeck.de/ -- You received this message because you are subscribed to the Google Groups "[email protected]" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/20221203 204840.1d25853a%40computer. -- You received this message because you are subscribed to the Google Groups "[email protected]" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/DM6PR14MB2186E967D78B611BBF5D76E692E19%40DM6PR14MB2186.namprd14.prod.outlook.com.
smime.p7s
Description: S/MIME cryptographic signature
