Malware-signing certs with 512-bit keys

[Peter Gutmann]

[NB: Crossposted to two lists where this issue has been discussed in the past]

So it seems like pretty much everyone (at least on these lists) has heard
about the Malaysian CA that issued 512-bit certs for which the keys were
factored and used to sign malware, and that had their CA cert pulled because
of this.

What's had much less (in fact apparently zero) attention is the fact that
Digicert Sdn. Bhd. only issued three of the nine certificates that were used
for malware signing. Three more were issued by Cybertrust, and one each by
GlobalSign, Taiwan-CA, and Anthem. The first three are root CAs, Anthem is
one of the vast number of you'll-only-find-out-they-exist-when-they're-used-
to-attack-you sub-CAs that are out there.

Given that the Malaysian CA had its cert pulled for this, can we get a
statment from browser vendors on whether Cybertrust, GlobalSign, and the
others will also similarly have their certs pulled for exactly the same
behaviour?

A rather interesting feature of the malware signatures is that although the
issuers look like random unconnected CAs, if you look at the signatures that
the nine certs were used with, each of them ends up at the GTE Cybertrust
(= Verizon, the last time I checked) root. Using data from the mid-2010 dates
in question:

http://www.securityspace.com/s_survey/data/man.201004/casurvey.html

gives them a 0.11% market share, but they represent 100% of the roots used for
the malware signatures. That just doesn't seem right.

Finally, there are even further 512-bit certs out there, some issued as
recently as a few months ago. The A-Data one in the collection below was
reported to the CA but they haven't taken any action (do they get their cert
pulled as well for that?). As the person who provided them commented, "so
knock yourself out, have the modulus factorized and sign some crazy code :-)".

Acknowledgements: Michael Sandee and Ondrej Mikle provided information for
this report. Any inadvertent mangling of details was my fault.

Peter.

-----BEGIN CERTIFICATE-----
MIIEMjCCAxqgAwIBAgIDCCiOMA0GCSqGSIb3DQEBBQUAMIGHMQswCQYDVQQGEwJB
VDFIMEYGA1UECgw/QS1UcnVzdCBHZXMuIGYuIFNpY2hlcmhlaXRzc3lzdGVtZSBp
bSBlbGVrdHIuIERhdGVudmVya2VociBHbWJIMRYwFAYDVQQLDA1hLXNpZ24tU1NM
LTAzMRYwFAYDVQQDDA1hLXNpZ24tU1NMLTAzMB4XDTEwMTEyMzEyMDYzMloXDTE1
MTEyMzEyMDYzMlowOTEgMB4GA1UEAwwXbW9id2ViZGF2LmhvY2hnZXJuZXIuYXQx
FTATBgNVBAUTDDY3OTU0Njc0MzMwNDBcMA0GCSqGSIb3DQEBAQUAA0sAMEgCQQCX
zfoFylBNoYtgK//wMeJ/0ihq1N8hfjr9gw1Tqgk6IeBDnFmxIqz6eSssC8N/HyBE
i2VGRlplzorD7Q0QGdazAgMBAAGjggG6MIIBtjATBgNVHSMEDDAKgAhAPqHTYrQD
3TByBggrBgEFBQcBAQRmMGQwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmEtdHJ1
c3QuYXQvb2NzcDA5BggrBgEFBQcwAoYtaHR0cDovL3d3dy5hLXRydXN0LmF0L2Nl
cnRzL2Etc2lnbi1zc2wtMDMuY3J0MEsGA1UdIAREMEIwQAYGKigAEQEUMDYwNAYI
KwYBBQUHAgEWKGh0dHA6Ly93d3cuYS10cnVzdC5hdC9kb2NzL2NwL2Etc2lnbi1z
c2wwgY8GA1UdHwSBhzCBhDCBgaB/oH2Ge2xkYXA6Ly9sZGFwLmEtdHJ1c3QuYXQv
b3U9YS1zaWduLVNTTC0wMyxvPUEtVHJ1c3QsYz1BVD9jZXJ0aWZpY2F0ZXJldm9j
YXRpb25saXN0P2Jhc2U/b2JqZWN0Y2xhc3M9ZWlkQ2VydGlmaWNhdGlvbkF1dGhv
cml0eTARBgNVHQ4ECgQIQjKcthkEWcUwDgYDVR0PAQH/BAQDAgWgMB4GA1UdEQQX
MBWBE3JvbWFuQGhvY2hnZXJuZXIuYXQwCQYDVR0TBAIwADANBgkqhkiG9w0BAQUF
AAOCAQEAJfdXmLQUKUQByU4WS2pthkD9QZW2CB498FwCfT/v69lgtzU8h8Hu1L1g
zVwG0GbitXk92rDxwF7XdU9MANFvGSxqKxGfcErZuqCX2+pYU4/zJCHlR6voYHoX
AJQPCY3PRM5USUWmysKaQ2wzwap8nqWpRMpcq+fUk49LR8CfFa9f63z++GthJtl6
d2OytiukgZ8Ea0edLyLDWr4B9UC+C+UhNJXjKtiMXHDYbbFmNzIszdUNOPuN4YI9
O2LG3YUH44McHiFGdU4WKtIOpkDJJPi7xPQp8uAOxCHnSFuJWem21ca/am1InMPG
hPWV3vw3Qht0GbhHrROdAu2Rxi5Kfg==
-----END CERTIFICATE-----

-----BEGIN CERTIFICATE-----
MIID0zCCArugAwIBAgIDLo6gMA0GCSqGSIb3DQEBBQUAME4xCzAJBgNVBAYTAkhL
MRYwFAYDVQQKEw1Ib25na29uZyBQb3N0MScwJQYDVQQDEx5Ib25na29uZyBQb3N0
IGUtQ2VydCBDQSAxIC0gMTAwHhcNMTEwODAyMDQwNjQxWhcNMTIwODI4MDgyNzUx
WjCBtTELMAkGA1UEBhMCSEsxJjAkBgNVBAoTHUhvbmdrb25nIFBvc3QgZS1DZXJ0
IChTZXJ2ZXIpMRMwEQYDVQQLEwowMDAxODUyODYwMSEwHwYDVQQLExgzODkxNzE1
MjAwMDAxMTEyMDAwTFA0MDkxKjAoBgNVBAsTIVRDSElCTyBNRVJDSEFORElTSU5H
IEhPTkcgS09ORyBMUDEaMBgGA1UEAxMRb3RzLnRjaGliby5jb20uaGswXDANBgkq
hkiG9w0BAQEFAANLADBIAkEA4K8j18RyT+8dXi396kNp+5/GbJsjDpYJYNDWo8Ba
pmJXDapaR3RHsbtmMmpnXjaBCH+s7cNxWy6BIgiQju3vEQIDAQABo4IBGDCCARQw
PgYDVR0gBDcwNTAzBgorBgEEAf0eAQETMCUwIwYIKwYBBQUHAgEWF3d3dy5ob25n
a29uZ3Bvc3QuZ292LmhrMAkGA1UdEwQCMAAwEQYJYIZIAYb4QgEBBAQDAgZAMA4G
A1UdDwEB/wQEAwIFIDBaBgNVHSMEUzBRoUukSTBHMQswCQYDVQQGEwJISzEWMBQG
A1UEChMNSG9uZ2tvbmcgUG9zdDEgMB4GA1UEAxMXSG9uZ2tvbmcgUG9zdCBSb290
IENBIDGCAgR5MEgGA1UdHwRBMD8wPaA7oDmGN2h0dHA6Ly9jcmwxLmhvbmdrb25n
cG9zdC5nb3YuaGsvY3JsL2VDZXJ0Q0ExLTEwQ1JMMS5jcmwwDQYJKoZIhvcNAQEF
BQADggEBAEBPvjxHDOFXYbkHeIWoF6Y3iODAtxYoDvPXIsEPYCS+MAyxWUYoOtIi
XHKnuSk17czOwsFsr/7rmKUID1lzH0l0/XduELw7SzsiwuSEFrS35Zsy8LYXdXLa
Y131CRGlM6ZTW6+OZRaavD0SC5S1ZACpSoG2DV5ZfvUgbqnJRpmGkA4VMC7cD2Iv
xCGNjGoS3XTmFC0ZFnwAelguyzqgCvIyR2cTAfKf0vyTOJq4ntD5ZCkQN9sKd4o6
0UNKI0KAjFOE6mdrEnKYTfIogYMLJAw+QtxF2KesTI00OrYCIWhrz/tZVKL8IXah
76Z3si0R7Dki1cHdVMrQrFRxExiSRPY=
-----END CERTIFICATE-----

-----BEGIN CERTIFICATE-----
MIID2zCCAsOgAwIBAgIDLi8KMA0GCSqGSIb3DQEBBQUAME4xCzAJBgNVBAYTAkhL
MRYwFAYDVQQKEw1Ib25na29uZyBQb3N0MScwJQYDVQQDEx5Ib25na29uZyBQb3N0
IGUtQ2VydCBDQSAxIC0gMTAwHhcNMTAxMDIwMDIyMzUxWhcNMTIxMTAzMDY0NzUw
WjCBvTELMAkGA1UEBhMCSEsxJjAkBgNVBAoTHUhvbmdrb25nIFBvc3QgZS1DZXJ0
IChTZXJ2ZXIpMRMwEQYDVQQLEwowMDAxNzYwOTg5MSUwIwYDVQQLExwwMDAwMDAw
MDAwMDAwMDAwMDAwMDAwMDBMQ1NEMSEwHwYDVQQLExhIb25nIEtvbmcgU0FSIEdv
dmVybm1lbnQxDTALBgNVBAsTBExDU0QxGDAWBgNVBAMTD29pYy5sY3NkLmdvdi5o
azBcMA0GCSqGSIb3DQEBAQUAA0sAMEgCQQDxH35W/jV6jNLBDJ1y9n+ANnjPfLLy
VrAicVMaK9/azMvt+xSfZ9+BSNbtF737Vj8hrohRrFWr/IOnb7oS8RT/AgMBAAGj
ggEYMIIBFDA+BgNVHSAENzA1MDMGCisGAQQB/R4BARMwJTAjBggrBgEFBQcCARYX
d3d3Lmhvbmdrb25ncG9zdC5nb3YuaGswCQYDVR0TBAIwADARBglghkgBhvhCAQEE
BAMCBkAwDgYDVR0PAQH/BAQDAgUgMFoGA1UdIwRTMFGhS6RJMEcxCzAJBgNVBAYT
AkhLMRYwFAYDVQQKEw1Ib25na29uZyBQb3N0MSAwHgYDVQQDExdIb25na29uZyBQ
b3N0IFJvb3QgQ0EgMYICBHkwSAYDVR0fBEEwPzA9oDugOYY3aHR0cDovL2NybDEu
aG9uZ2tvbmdwb3N0Lmdvdi5oay9jcmwvZUNlcnRDQTEtMTBDUkwxLmNybDANBgkq
hkiG9w0BAQUFAAOCAQEAEMFWGh83PWc61ymoOFv0tvo8xMkQQmB+vO3MWhBf8YzS
aEetmYVP5O1LINV5KHHWpT5EZMIIA3ffRD7QVkRZOxPFewkLWK6UaujV9XevP2Fe
RotXs0tPpOHQbz5+z7ZCRvQBxayT+O/dQopKC0gfDEvDvJrV+6Mlelkric+mPkSM
x5zYaRdqMupVUTvYiY8D/dtG9ITrpk/lhVKcIJzwY0EFRCVUoUX1ldAEn4gyckMP
VSrG8qtuZmzsv8JjFOcwpDe+5Ull/87SCw3KUmnA0VNbU26WfzPYhTEBIizbj4dI
YinocNVD3+LRLubcgApi7YI0aepeBYns+OOOfwL+RQ==
-----END CERTIFICATE-----

-----BEGIN CERTIFICATE-----
MIID2zCCAsOgAwIBAgIDLi8KMA0GCSqGSIb3DQEBBQUAME4xCzAJBgNVBAYTAkhL
MRYwFAYDVQQKEw1Ib25na29uZyBQb3N0MScwJQYDVQQDEx5Ib25na29uZyBQb3N0
IGUtQ2VydCBDQSAxIC0gMTAwHhcNMTAxMDIwMDIyMzUxWhcNMTIxMTAzMDY0NzUw
WjCBvTELMAkGA1UEBhMCSEsxJjAkBgNVBAoTHUhvbmdrb25nIFBvc3QgZS1DZXJ0
IChTZXJ2ZXIpMRMwEQYDVQQLEwowMDAxNzYwOTg5MSUwIwYDVQQLExwwMDAwMDAw
MDAwMDAwMDAwMDAwMDAwMDBMQ1NEMSEwHwYDVQQLExhIb25nIEtvbmcgU0FSIEdv
dmVybm1lbnQxDTALBgNVBAsTBExDU0QxGDAWBgNVBAMTD29pYy5sY3NkLmdvdi5o
azBcMA0GCSqGSIb3DQEBAQUAA0sAMEgCQQDxH35W/jV6jNLBDJ1y9n+ANnjPfLLy
VrAicVMaK9/azMvt+xSfZ9+BSNbtF737Vj8hrohRrFWr/IOnb7oS8RT/AgMBAAGj
ggEYMIIBFDA+BgNVHSAENzA1MDMGCisGAQQB/R4BARMwJTAjBggrBgEFBQcCARYX
d3d3Lmhvbmdrb25ncG9zdC5nb3YuaGswCQYDVR0TBAIwADARBglghkgBhvhCAQEE
BAMCBkAwDgYDVR0PAQH/BAQDAgUgMFoGA1UdIwRTMFGhS6RJMEcxCzAJBgNVBAYT
AkhLMRYwFAYDVQQKEw1Ib25na29uZyBQb3N0MSAwHgYDVQQDExdIb25na29uZyBQ
b3N0IFJvb3QgQ0EgMYICBHkwSAYDVR0fBEEwPzA9oDugOYY3aHR0cDovL2NybDEu
aG9uZ2tvbmdwb3N0Lmdvdi5oay9jcmwvZUNlcnRDQTEtMTBDUkwxLmNybDANBgkq
hkiG9w0BAQUFAAOCAQEAEMFWGh83PWc61ymoOFv0tvo8xMkQQmB+vO3MWhBf8YzS
aEetmYVP5O1LINV5KHHWpT5EZMIIA3ffRD7QVkRZOxPFewkLWK6UaujV9XevP2Fe
RotXs0tPpOHQbz5+z7ZCRvQBxayT+O/dQopKC0gfDEvDvJrV+6Mlelkric+mPkSM
x5zYaRdqMupVUTvYiY8D/dtG9ITrpk/lhVKcIJzwY0EFRCVUoUX1ldAEn4gyckMP
VSrG8qtuZmzsv8JjFOcwpDe+5Ull/87SCw3KUmnA0VNbU26WfzPYhTEBIizbj4dI
YinocNVD3+LRLubcgApi7YI0aepeBYns+OOOfwL+RQ==
-----END CERTIFICATE-----

-----BEGIN CERTIFICATE-----
MIID6TCCAtGgAwIBAgIDLi62MA0GCSqGSIb3DQEBBQUAME4xCzAJBgNVBAYTAkhL
MRYwFAYDVQQKEw1Ib25na29uZyBQb3N0MScwJQYDVQQDEx5Ib25na29uZyBQb3N0
IGUtQ2VydCBDQSAxIC0gMTAwHhcNMTAxMDE5MDM0MzE0WhcNMTIxMTA3MDMxMzI3
WjCByzELMAkGA1UEBhMCSEsxJjAkBgNVBAoTHUhvbmdrb25nIFBvc3QgZS1DZXJ0
IChTZXJ2ZXIpMRMwEQYDVQQLEwowMDAxODU2ODU4MSEwHwYDVQQLExgzMDI4ODIy
MDAwMDA1MDhBMDA2NzcxNDcxPDA6BgNVBAsTM0ZBUlJJTkdUT04gQU1FUklDQU4g
RVhQUkVTUyBUUkFWRUwgU0VSVklDRVMgTElNSVRFRDEeMBwGA1UEAxMVd3d3LmFt
ZXh0cmF2ZWwuY29tLmhrMFwwDQYJKoZIhvcNAQEBBQADSwAwSAJBAM9OjldrW2Ar
jiLKl6MhSFzonx787bsy54r/cmKhsH+wb27BVf/Oo1Da4oPerVDH1DG3E3WRsoNc
Ew5bN5lYiHUCAwEAAaOCARgwggEUMD4GA1UdIAQ3MDUwMwYKKwYBBAH9HgEBEzAl
MCMGCCsGAQUFBwIBFhd3d3cuaG9uZ2tvbmdwb3N0Lmdvdi5oazAJBgNVHRMEAjAA
MBEGCWCGSAGG+EIBAQQEAwIGQDAOBgNVHQ8BAf8EBAMCBSAwWgYDVR0jBFMwUaFL
pEkwRzELMAkGA1UEBhMCSEsxFjAUBgNVBAoTDUhvbmdrb25nIFBvc3QxIDAeBgNV
BAMTF0hvbmdrb25nIFBvc3QgUm9vdCBDQSAxggIEeTBIBgNVHR8EQTA/MD2gO6A5
hjdodHRwOi8vY3JsMS5ob25na29uZ3Bvc3QuZ292LmhrL2NybC9lQ2VydENBMS0x
MENSTDEuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQAqIGebX6Iqm1pRg9JkuVzdAfpA
TDqO7S/4pZNXC9ZIp+fv/1sLIJiNwhmtMhyuO6h8wWkiMREP34orSXJ0xLks/JPM
cmyuSb12DduUPVFYnykEYtDHUD+By+62u08Gg0VeBNuSzPDWHFlVEHweCsbaDrvo
+eN3s1v8mDduWE5iNkAwGbtnDC4mKgj66TIip15YAlHxF9U0X6Iaq03L+oXxy76n
BAUke1picAgMX5ShALRlGuOUOFI0Yi4S383xuXOE0ZjgOobNArFIDZbSkEtTiEyl
PrM/QFq8c7K/mhO7Wsrt0TBBauIVqKA/irIKpg+jeJG+lL6JP7/9P1yTSVma
-----END CERTIFICATE-----

-----BEGIN CERTIFICATE-----
MIID6zCCAtOgAwIBAgIDI4qRMA0GCSqGSIb3DQEBBQUAMEkxCzAJBgNVBAYTAkhL
MRYwFAYDVQQKEw1Ib25na29uZyBQb3N0MSIwIAYDVQQDExlIb25na29uZyBQb3N0
IGUtQ2VydCBDQSAxMB4XDTA5MTEyMzA0MjkyMVoXDTExMTIwOTAzMjMzOFowgdUx
CzAJBgNVBAYTAkhLMSYwJAYDVQQKEx1Ib25na29uZyBQb3N0IGUtQ2VydCAoU2Vy
dmVyKTETMBEGA1UECxMKMDAwMTIxMDkzMTEnMCUGA1UECxMeMDAwMDAwMDAwMDAw
MDAwMDAwMDAwMDAwREgtUkhVMSEwHwYDVQQLExhIb25nIEtvbmcgU0FSIEdvdmVy
bm1lbnQxITAfBgNVBAsTGERILVJhZGlhdGlvbiBIZWFsdGggVW5pdDEaMBgGA1UE
AxMRd3d3LmRoLXJodS5nb3YuaGswXDANBgkqhkiG9w0BAQEFAANLADBIAkEAoqbv
uYXV9xswou8XILtutEmdT9kwUMb5ltUdBSDGQcAz/Ku1r/rG22JG5Wenih7Du1tt
qzpKEbKgtSAaEjSe0wIDAQABo4IBFTCCAREwPgYDVR0gBDcwNTAzBgorBgEEAf0e
AQEQMCUwIwYIKwYBBQUHAgEWF3d3dy5ob25na29uZ3Bvc3QuZ292LmhrMAkGA1Ud
EwQCMAAwEQYJYIZIAYb4QgEBBAQDAgZAMA4GA1UdDwEB/wQEAwIFIDBaBgNVHSME
UzBRoUukSTBHMQswCQYDVQQGEwJISzEWMBQGA1UEChMNSG9uZ2tvbmcgUG9zdDEg
MB4GA1UEAxMXSG9uZ2tvbmcgUG9zdCBSb290IENBIDGCAgPtMEUGA1UdHwQ+MDww
OqA4oDaGNGh0dHA6Ly9jcmwxLmhvbmdrb25ncG9zdC5nb3YuaGsvY3JsL2VDZXJ0
Q0ExQ1JMMi5jcmwwDQYJKoZIhvcNAQEFBQADggEBAAu625vond5fw/D2B2a0Cj4S
5OMtNOKxzR485W3UoTV/b7ABx13QRKwJK3AWlMwRY7HzbHtDQOHg2HiXvXICpYsq
J3PKRotpR+s7yXKjxxtEY0o/cdlYMTTHc443ZIYvDQBbI2CPJsSD8O6q+4dxj1Qp
w3H/pCFoZ/z7tNK7nzVuVQolLbruVv5i99dGCa2kNN5+2qgp9aV8G4vo1GpLxpi/
rb/ZUvCDqzOeigmewW/vtGZe0mOZJW29EMLEXBfzcrW2iIw7TClvIGxaQXrxFjAc
zu1JEq19/96d7sMkIxdWGW9BfOoY9zMFb9w5srUupK7Z/Y8Ydn/DBsOrnS6AxMQ=
-----END CERTIFICATE-----

-----BEGIN CERTIFICATE-----
MIID3DCCAsSgAwIBAgIDLm8+MA0GCSqGSIb3DQEBBQUAME4xCzAJBgNVBAYTAkhL
MRYwFAYDVQQKEw1Ib25na29uZyBQb3N0MScwJQYDVQQDEx5Ib25na29uZyBQb3N0
IGUtQ2VydCBDQSAxIC0gMTAwHhcNMTEwNDI2MDI1MzA0WhcNMTMwNTE5MDcyODA5
WjCBvjELMAkGA1UEBhMCSEsxJjAkBgNVBAoTHUhvbmdrb25nIFBvc3QgZS1DZXJ0
IChTZXJ2ZXIpMRMwEQYDVQQLEwowMDAxODQ4NzM4MSUwIwYDVQQLExwwMDAwMDAw
MDAwMDAwMDAwMDAwMDAwMDBMQ1NEMSEwHwYDVQQLExhIb25nIEtvbmcgU0FSIEdv
dmVybm1lbnQxDTALBgNVBAsTBExDU0QxGTAXBgNVBAMTEGltdHMubGNzZC5nb3Yu
aGswXDANBgkqhkiG9w0BAQEFAANLADBIAkEAyey2HOeEHR459PxjQwBQmX8Z8AJ0
IemQhl19uXZJcd6IGOtcFrCWOKT1/pEn1IxzeAejErxAVJAUSoDqnMq1qQIDAQAB
o4IBGDCCARQwPgYDVR0gBDcwNTAzBgorBgEEAf0eAQETMCUwIwYIKwYBBQUHAgEW
F3d3dy5ob25na29uZ3Bvc3QuZ292LmhrMAkGA1UdEwQCMAAwEQYJYIZIAYb4QgEB
BAQDAgZAMA4GA1UdDwEB/wQEAwIFIDBaBgNVHSMEUzBRoUukSTBHMQswCQYDVQQG
EwJISzEWMBQGA1UEChMNSG9uZ2tvbmcgUG9zdDEgMB4GA1UEAxMXSG9uZ2tvbmcg
UG9zdCBSb290IENBIDGCAgR5MEgGA1UdHwRBMD8wPaA7oDmGN2h0dHA6Ly9jcmwx
Lmhvbmdrb25ncG9zdC5nb3YuaGsvY3JsL2VDZXJ0Q0ExLTEwQ1JMMS5jcmwwDQYJ
KoZIhvcNAQEFBQADggEBAFSjUZ7jGO593Gt2soWUQmDsEhLlRRaW3V4cyr7glVL5
9UIw+Zn4fciiLTAgXsG6DSaxcsoDZSWxFzjgZCGGw2rWnSnHxbXWQudD3y+jnPC9
h4j/XB8XRkdPDyESOJkF1cwPqYsqZZV+gvMBO9nU7W4q8nt6WCy6qi5DOiHtzyea
NO+hQJAd807ge9pKdveH8hPbZdMSBAmhkZZSMN14ItyfEqe1wNCNv6siRtUgzfp8
0G9fV8OoZATYOHlqLuFrXcyRwGqPu/rwcMb1fDyf7PM5L9JerwDsz1ygIgCwmKTV
vH4ElrId5uf3mSBt87bkvwLT3VGKS0eldjbIhEwp4Ns=
-----END CERTIFICATE-----

[Ondrej Mikle]

On 12/07/2011 01:30 PM, Peter Gutmann wrote:
> Finally, there are even further 512-bit certs out there, some issued as
> recently as a few months ago. The A-Data one in the collection below was

It's issued by A-Trust (not A-Data).

The Hongkong Post certs lack EKU extension, but 'key usage' does not
contain 'digital signature'. That makes them probably unusable for
Microsoft's code-signing scheme, but I don't know about other
code-signing implementations.

Ondrej

[Rob Stradling]

AIUI, the Digicert Sdn. Bhd. Intermediate CA Certificate was blacklisted by the
major browsers due to multiple failings:
1. Recent certification of RSA-512 keys (which violated in-force policy
requirements that RSA-1024 is the absolute minimum RSA key size).
2. Extended Key Usage extension absent from end-entity Server certs (meaning
that these certs could be repurposed for signing malware).
3. Both CRL and OCSP URLs absent from end-entity certs (meaning that the CA
had no way of revoking the certs).

The certs you've just cited all suffer from failings 1 and 2 (although the 6
Hongkong Post certs do specify a Netscape Cert Type of SSL Server, an
extension which I think modern Mozilla-based browsers still recognize - so
this should prevent repurposing for malware signing, at least for Mozilla's
users).

These certs do all provide CRL and/or OCSP URLs. But if, as you say, A-Trust
have been notified but have failed to revoke, then right now AFAICT the A-Trust
cert you've provided poses just as much risk to the general public as the
DigiCert Sdn. Bhd. certs posed!

(Cue a reply from Peter re: the inefficacy of OCSP...)

> Finally, there are even further 512-bit certs out there, some issued as
> recently as a few months ago. The A-Data one in the collection below was

> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy

Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
Office Tel: +44.(0)1274.730505
Office Fax: +44.(0)1274.730909
www.comodo.com

COMODO CA Limited, Registered in England No. 04058690
Registered Office:
3rd Floor, 26 Office Village, Exchange Quay,
Trafford Road, Salford, Manchester M5 3EQ

This e-mail and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom they are addressed.
If you have received this email in error please notify the sender by replying
to the e-mail containing this attachment. Replies to this email may be
monitored by Comodo for operational or business reasons. Whilst every
endeavour is taken to ensure that e-mails are free from viruses, no liability
can be accepted and the recipient is requested to use their own virus checking
software.

[Rob Stradling]

On Wednesday 07 Dec 2011 13:17:04 Ondrej Mikle wrote:
> On 12/07/2011 01:30 PM, Peter Gutmann wrote:

> > Finally, there are even further 512-bit certs out there, some issued as
> > recently as a few months ago. The A-Data one in the collection below was
>

> It's issued by A-Trust (not A-Data).
>
> The Hongkong Post certs lack EKU extension, but 'key usage' does not
> contain 'digital signature'. That makes them probably unusable for
> Microsoft's code-signing scheme, but I don't know about other
> code-signing implementations.

Good point.

The A-Trust cert does contain the Key Usage extension, but this doesn't
prevent repurposing for malware signing because the digitalSignature bit is
set.

> Ondrej

[Rob Stradling]

[Peter Gutmann]

Ondrej Mikle <ondrej...@nic.cz> writes:

>It's issued by A-Trust (not A-Data).

Well I had to put something in there to validate the "Any inadvertent mangling
of details was my fault" :-).

>The Hongkong Post certs lack EKU extension, but 'key usage' does not contain
>'digital signature'. That makes them probably unusable for Microsoft's code-
>signing scheme, but I don't know about other code-signing implementations.

How effectively is that enforced though? CryptoAPI will quite happily allow
the use of encryption-only keys (AT_KEYEXCHANGE in CryptoAPI terminology) to
be used for signature generation and verification (amusingly, the CryptoAPI
workhorse signature-generation function CryptSignHash(), while on the one hand
not allowing you to select from among your signature keys the one that you
want to use for signing does on the other hand allow you to indicate
specifically that you want to use your AT_KEYEXCHANGE encryption key to
generate a signature). In the past developers have had considerable problems
getting (for example) Windows to stop using a kU digitalSignature-flagged cert
for encryption. So just because the kU is set a certain way doesn't mean it
won't be used for something completely different.

Peter.

[ianG]

On 7/12/11 23:30 PM, Peter Gutmann wrote:
> [NB: Crossposted to two lists where this issue has been discussed in the past]
>
> So it seems like pretty much everyone (at least on these lists) has heard
> about the Malaysian CA that issued 512-bit certs for which the keys were
> factored and used to sign malware, and that had their CA cert pulled because
> of this.
>
> What's had much less (in fact apparently zero) attention

As someone commented to me today, in PKI, any news is good news. As the
old aphorism from PT Barnum suggests, facts should not be allowed to
interfere with the serious business of advertising.
http://en.wikipedia.org/wiki/P._T._Barnum

> is the fact that
> Digicert Sdn. Bhd. only issued three of the nine certificates that were used
> for malware signing. Three more were issued by Cybertrust, and one each by
> GlobalSign, Taiwan-CA, and Anthem. The first three are root CAs, Anthem is
> one of the vast number of you'll-only-find-out-they-exist-when-they're-used-
> to-attack-you sub-CAs that are out there.

9 certs of 512 bits size were used in various malware signing attacks,
and nothing larger was seen. So it is claimed. So it is probably
reasonable to suggest a private key crunching attack on those certs. On
the other hand, we don't have enough to rule out the alternates. IMHO.

Still, with this reasonable conjecture in hand, that's probably
sufficient for relying parties (vendors as defined in BR) to up the
acceptable limit to the next reasonable notch. I'd suggest 768, vendors
will do 1024 I guess.

Given the facts (number of attacks, 9?; the number of users, 250m;
slowness of updates; lack of reported direct damages) a vendor might
reasonably wait until the next convenient release?

> Given that the Malaysian CA had its cert pulled for this, can we get a
> statment from browser vendors on whether Cybertrust, GlobalSign, and the
> others will also similarly have their certs pulled for exactly the same
> behaviour?

It is curious.

When we wrote the Mozilla policy, we inserted that Mozilla had the sole
right to decide when to pull a root. When I suggested that (yes, blame
me now) I knew that any suggestion to pull a root would immediately
cause a counter-balancing lawsuit by CAs with cashflow in mind. (Which
would win, ask your lawyer how to stop anything with an injunction.)

Oh, and it was impractical to iterate in advance the reasons & causes
for pulling a root.

Now I find myself on the other camp - wanting more definate statements.
I think there are many discrepencies over time: unusual claims made by
vendors ("issued certs in breach of their own CPS" and "failure to
notify relying parties"), policy & practice by herd, lack of
transparency in vendors' actions, and recent allegations that some
(sub-)roots are being used for routine MITMing.

I feel that PKI is entering a crisis phase, much like Europe's
finances. Things are going to get worse. So, the question really is,
are we going to ask the hard questions and start dealing with some hard
answers, or are we going to kick the can along the road a bit more?
Worked for Europe, right?

The MITM evidenced in the above attacks was or wasn't a reason to pull a
root? Is MITM a reason to pull a root? Sufficient reason?

Or, what is?

And, is that it? We'll keep burying roots until the pain goes away?

iang

[Christoph Klein]

Hi!

My name is Christoph Klein and I work at A-Trust in Austria. We have investigated the certificate in question and instantly revoked it after talking to the owner of the domain. We performed further testing and found out, that this was the only certificate issued by our SSL CA with a keylength below 1024.

Our policy forbids the issuing of SSL certificates with keylenghts below 1024 bit. This rule was solely enforced through a manual check by the agent and that is how the error has occured. To avoid such a mistake in future, we have deployed an additional control in our CA. This check will assure, that no more certificates with a keylenght below 1024 can be created.

Regards,
Christoph Klein
A-Trust GmbH

[Christoph Klein]

[Ondrej Mikle]

On 12/15/11 17:23, Christoph Klein wrote:
> My name is Christoph Klein and I work at A-Trust in Austria. We have investigated the certificate in question and instantly revoked it after talking to the owner of the domain.

Great that the cert is revoked.

> We performed further testing and found out, that this was the only certificate issued by our SSL CA with a keylength below 1024.

Uhm...that was the last valid one. There were two more 512-bit ones. Following
one has been revoked this year (but the site in subject CN is still sending it):

-----BEGIN CERTIFICATE-----
MIIEhjCCA26gAwIBAgIDBQrsMA0GCSqGSIb3DQEBBQUAMIGHMQswCQYDVQQGEwJB
VDFIMEYGA1UECgw/QS1UcnVzdCBHZXMuIGYuIFNpY2hlcmhlaXRzc3lzdGVtZSBp
bSBlbGVrdHIuIERhdGVudmVya2VociBHbWJIMRYwFAYDVQQLDA1hLXNpZ24tU1NM
LTAzMRYwFAYDVQQDDA1hLXNpZ24tU1NMLTAzMB4XDTA5MDIyMzA5NDMyNloXDTE0
MDIyMzA5NDMyNlowgYsxCzAJBgNVBAYTAkFUMTAwLgYDVQQKDCdXZWluaGFuZGwg
JiBQYXJ0bmVyIEVEVi1Db25zdWx0aW5nIEdtYkgxFTATBgNVBAsMDElULUFidGVp
bHVuZzEcMBoGA1UEAwwTd3d3LmFjcy1wcmVtaXVtLmNvbTEVMBMGA1UEBRMMNDE1
NTI2MzkxODI2MFwwDQYJKoZIhvcNAQEBBQADSwAwSAJBAOGRI4W/QVZHwevEVHaI
Kh4rr7a1vzVMtN+onFKiwMUDhHqF4G3S8I3ifWX8NFbg5IDZhr8iyauQq/1RvQKl
IbUCAwEAAaOCAbswggG3MBMGA1UdIwQMMAqACEA+odNitAPdMHIGCCsGAQUFBwEB
BGYwZDAnBggrBgEFBQcwAYYbaHR0cDovL29jc3AuYS10cnVzdC5hdC9vY3NwMDkG
CCsGAQUFBzAChi1odHRwOi8vd3d3LmEtdHJ1c3QuYXQvY2VydHMvYS1zaWduLXNz
bC0wMy5jcnQwSwYDVR0gBEQwQjBABgYqKAARARQwNjA0BggrBgEFBQcCARYoaHR0
cDovL3d3dy5hLXRydXN0LmF0L2RvY3MvY3AvYS1zaWduLXNzbDCBjwYDVR0fBIGH
MIGEMIGBoH+gfYZ7bGRhcDovL2xkYXAuYS10cnVzdC5hdC9vdT1hLXNpZ24tU1NM
LTAzLG89QS1UcnVzdCxjPUFUP2NlcnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q/YmFz
ZT9vYmplY3RjbGFzcz1laWRDZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MBEGA1UdDgQK
BAhN+DMMcvaCMDAOBgNVHQ8BAf8EBAMCBaAwHwYDVR0RBBgwFoEUb2ZmaWNlQHdl
aW5oYW5kbC5jb20wCQYDVR0TBAIwADANBgkqhkiG9w0BAQUFAAOCAQEAld3eAHOx
/pzqlEGKw9s1FhX/bgHoUVo2YYCJVZKMNJ8Pas0LkDmo9HPTHe0Ljx+Zs71FZ7Mp
MHPVnInhcycf9Uha6ypbKtgthOhRabPhcGsdbN9LxZXoVJedUqgtaeccWt40AHG1
HAEYZokLK7NinMcg9UXSmWz0/S0W/69j8OojFSyEgxgQvwzu5u2fMrOmi3eRKUiJ
0yczrKC9EjWV5frKb/ntxW9hqUZxUI6OSlC7G9MQ1kVXC/URM7IQk3XmIWd3U92F
7bwkc4JyjO4FsdbMbGP810R6j6/38yYHoIWtXSxJuZtmWM/vjiSQMoJNhAIoGjDT
AZ0eOiApJ2XA8A==
-----END CERTIFICATE-----

The third one expired a year ago without revocation, serial no. 0x1bc41, subject
CN: secure.selectstrom.at, issuer: "C=AT, O=A-Trust Ges. f. Sicherheitssysteme
im elektr. Datenverkehr GmbH, OU=a-sign-corporate-light-02,
CN=a-sign-corporate-light-02"


Ondrej