[Bimi] No cryptographic connection between VMC and DKIM key

[Hanno Böck <[e-mail]>]

Hello,

I wanted to share an observation about the BIMI specification.
While I would like to say that this is not directly a security
vulnerability, it is in my view an extremely surprising design decision
that makes other vulnerabilities more likely to have a higher impact.

BIMI introduces the concept of a "Verified Mark Certificate". This
means involving a certificate authority, and having an X.509
certificate with a cryptographic key.

On the other hand, BIMI relies on DMARC and by extension DKIM, and once
a mail has a DMARC policy with either reject or quarantine and a valid
DKIM signature, that mail passes BIMI's requirements.

To my surprise, there is no cryptographic connection between the two.
The cryptographic key in the certificate is not used at all. The only
cryptographic key that matters is the DKIM key. If an attacker gets
access to the DKIM private key, messages can be forged, and they will
not just pass DKIM and DMARC, but als BIMI validation.

This has some consequences. In other areas where certifiate authorites
are involved - like the WebPKI - it is expected that CAs do basic
checking of cryptographic keys and enforce minimum security standards.
E.g., it has long been the case that certificate authorities would not
issue certificates for RSA keys shorter than 2048 bit. CAs are also
expected to not issue certificates for known-compromised keys, or
revoke them if they are made aware of a compromise.

I can personally say from my own research that this approach has a
notable effect: Finding compromised keys within the WebPKI ecosystem is
relatively rare.

None of that is true for DKIM. One can even find hosts with DKIM keys
configured with 512 bit RSA keys and a corresponding BIMI record. 512
bit RSA can be broken on consumer hardware within days with freely
available software. The majority of DKIM RSA keys are 1024 bit, which
is considered to be breakable by powerful attackers, although it has
not been publicly shown.

In essence, while BIMI introduces the complexity of having another
certificate authority ecosystem, it does not introduce the security
that should come with that. It would've easily been possible to design
it in a different way. One could, e.g., imagine that the DKIM key would
have to match the key in the VMC, or that mails get an additional
DKIM-alike signature with the VMC key.

One wonders whether the certificate authorities selling BIMI
certificates for thousands of dollars at least try to educate their
customers about cryptographic security. They could, for example,
monitor the DKIM keys their customers use on common selectors and warn
them if they use substandard cryptography. Based on my observations, I
do not think that CAs do that.


I guess some may consider what I just said as an unimportant or a
merely theoretical issue, so I would like to illustrate it with an
example. Let's take the domain entrust.com. It has a DKIM key
configured at "dkim._domainkey.entrust.com". The TXT record is the
following:

"v=DKIM1; k=rsa;
p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCyGF0xzO7Eig1H8QdIErjEKOGnIVvoLU5VjcMRBRWZK65NinL+gVnjuMD2mYdjC3f+7sQCWxGDSKIFn/bB+iXxO2x1/ktkwXHQfQ/9FcFuy+LE0Snsm0SwXN/2l1m5f9e1xdswC+dzHt6DIpDSDENsRal019YKQTqwVyB++7QORwIDAQAB"

This is a 1024 bit RSA key, which is not up to modern standards. But
breaking 1024 bit RSA is still only feasible for very powerful
attackers. However, this key has another problem: it is vulnerable to
the Debian OpenSSL bug (CVE-2008-0166). It is trivially possible to
find the private key (you can use my tool badkeys -
https://badkeys.info/ - to do that):

https://github.com/badkeys/debianopenssl/blob/main/rsa1024/ssl/le32/25731-rnd.key

-----BEGIN RSA PRIVATE KEY-----
MIICWwIBAAKBgQCyGF0xzO7Eig1H8QdIErjEKOGnIVvoLU5VjcMRBRWZK65NinL+
gVnjuMD2mYdjC3f+7sQCWxGDSKIFn/bB+iXxO2x1/ktkwXHQfQ/9FcFuy+LE0Sns
m0SwXN/2l1m5f9e1xdswC+dzHt6DIpDSDENsRal019YKQTqwVyB++7QORwIDAQAB
AoGAH7zFxt0tY6ryaPKkCI0Fjjd21xDTzxFb11U3AO52BeDJ5BmbGo20lidTg96i
SN0/Whf0qDLQcSPdc8Eo+TJ51jIbLPdy16Rn7cPPJzUDIzJPas4ewkI7lsU37hlC
cr7T521l8g6w/mS2TtTZykpsHvb0tztjQuElS7TxWUuVuskCQQDmrvjJU3u9CMkb
3avhUAXlsK4nboo8GTPt4Ss9O2/ipTx3K+qtAfHM7HiZie3iYwxCKQQ3MdMlmh/N
fPR/rTS9AkEAxaPt3EN8wB4w95FAQd9J338n1hXF0lE7UH1aBemuIbWXgY1UTlL4
X1Kx7rLeuQv8mzFkuQyXSFbq7eBXSBOZUwJACKxLbkZVQKYz6XhMHgyELD6YTaM6
T0gjS65LkeHKMxtDSre7+wU3shyx7BPjfb97loE0R174MVG6IF+yUZqRgQJALhtt
LTqNSuCAOfEn1XY67KnkaDxSFxueQ8vKiaCXYAPWIYIQDemrScmn+vC9ptvWBXqD
bewzCsxEKFRy6DyyQwJAGVyC2vMIL7aeMhB+V9YVDZJlV3MEGCYmbF84ZtLhSWTX
QfUe81qGdL3IBMRqz2GnSS0y7qPN/8CP5W9cKy8aDg==
-----END RSA PRIVATE KEY-----

You can then use a command like dkimsign (part of dkimpy) to create a
signed mail:

dkimsign dkim entrust.com 25731-rnd.key < unsigned.txt > signed.txt

You can find a signed test mail here:
https://16years.secvuln.info/testmail.msg

Given that this host has a default BIMI record, those signed mails will
automatically pass BIMI validation.

For more information, you may also want to check out:
https://16years.secvuln.info/


-- 
Hanno Böck - Independent security researcher
https://itsec.hboeck.de/