Microsoft, Mozilla and Google Ban Malaysian Intermediate CA

Orome1 writes "Microsoft, Mozilla and Google have announced that they are revoking trust in Malaysia-based DigiCert, an intermediate certificate authority authorized by well-known CA Entrust, following the issuing of 22 certificates with weak keys, lacking in usage extensions and revocation information. 'There is no indication that any certificates were issued fraudulently, however, these weak keys have allowed some of the certificates to be compromised,' wrote Jerry Bryant of Microsoft's Trustworthy Computing."

Comments

Not related to the US Digicert

[swb]

It might have been nice to mention that in the article summary.

Re:Not related to the US Digicert

[psydeshow]

It might have been nice to mention that in the article summary.

Indeed. From the article:

Both Mozilla and Microsoft made sure to note that there is no relationship between DigiCert Malaysia and Utah-based DigiCert Inc., which is a member of the Windows Root Certificate Program and Mozilla’s root program.

Whew!

Who generates 512-bit RSA keys these days?

[heypete]

RSA-512 has been known to be weak for a long time.

Who in their right mind would generate such a certificate for (presumably) a production system?

Why didn't the CA have some sort of system to detect such short keys?

The CA I use doesn't allow anything less than 2048-bits to be signed. While the policy may be a bit strict, as 1024-bit keys still have their uses (there's a lot of hardware that only deals with 1024-bit keys), at least they're erring on the side of caution. I'm sure they're not the only one with such a policy.

Re:Who generates 512-bit RSA keys these days?

[yuhong]

Except it doesn't, as the bad cert was also "missing certificate extensions", which means it can be used for any purpose after the private key is factored out, and indeed from one of the articles:

"I have been contacted by Entrust who say that two of the certificates issued by the Malaysian DigiCert Sdn. Bhd. were used to sign malware used in a spear phishing attack against another Asian certificate authority," reports Sophos' Chester Wisniewski.

Re:Who generates 512-bit RSA keys these days?

[heypete]

That's a good question. I will attempt to answer it, with the caveat that I'm also not a crypto expert.

Most of the relatively shorter key lengths you see these days, such as 128-bit and 256-bit refer to symmetric encryption algorithms like AES. At this point in time, such keylengths are secure for the foreseeable future. These algorithms tend to be quite fast (AES has hardware-acceleration in many CPUs, which can encrypt or decrypt data at 1GB+/sec in some cases, and around 300MB/sec on many non-accelerated CPUs), but require that both parties exchanging encrypted data share the same key. (Hence the name "symmetric" -- the same key is used for encrypting and decrypting.)

The two parties could previous exchange a shared symmetric key by means of a trusted channel, like a trusted courier, or meeting in person. This can be extremely difficult in the real-world, though.

The longer-length keys you often see (1024-bit, 2048-bit, 4096-bit and, in the case mentioned in the article, the not-very-secure-at-all 512-bit length) are "asymmetric" keys -- when they're created, one creates a "public key" and a "private key" that are linked a certain mathematical way. The public key can be distributed widely, while the private key must be kept secret. If Alice wants to send Bob a secure message, she can encrypt it with Bob's public key, but the message can only be decrypted with Bob's private key -- even if someone intercepts the encrypted message and has Bob's public key, they are unable to decrypt it.

Asymmetric encryption is extremely slow, relative to symmetric encryption (I seem to recall reading that they're about a thousand times slower). Sending large amounts of data over secure connections would be extremely slow. Fortunately, modern cryptosystems use a hybrid model: they use asymmetric keys to exchange a shared secret key that is then used for faster symmetric encryption -- this allows for quick symmetric encryption methods to be used by solving the problem of exchanging the symmetric key without needing to meet in person.

SSL, for example, uses such a method. A simplified description follows: when your browser connects to a secure website the server sends you its public key (which has been digitally signed by a certificate authority who vouches for the identity of the server). Your browser checks the signature to make sure it's actually been issued by the authority and, if it checks out, creates a random symmetric key, encrypts it with the server's public key and sends it to the server. The server decrypts the symmetric key with its private key. Both client and server then encrypt all future communications with the symmetric key.

Because asymmetric and symmetric encryption keys use entirely different mathematical methods to secure data, their keylengths aren't directly comparable. According to NIST, a 3072-bit asymmetric key is about as strong as a 128-bit symmetric key.

See and for more details.

Re:I thought Linux was so secure slashdotters

[0123456]

I know! I posted my root password on my web site and some asshole hacked into it. And they told me Linux was secure! I'm switching to Windows!

Re:Hello? Apple?

[Desler]

I hate to piss on your trolling but this CA is not a trusted authority in iOS.

Re:I thought Linux was so secure slashdotters

[MysteriousPreacher]

I wonder if there's something for Linux that's equivalent to Blizzard's Warcraft password inspector. He contacted me last week, asking to inspect my password to ensure that it's secure. It was kind of embarrassing that my account got hacked, and my credit card maxed out, shortly after I'd sent him my password. Fortunately though I was able to regain access and change my password. I forwarded the new password to the inspector and apologized if he had trouble trying to use the old one. Email the Blizzard guy to see if he knows the Linux password inspector. His address is paswordinspecter@blizzard-account-admin.shulinhost.cn

Eliminate Intermediate CA's, restrict root CA's.

[ad454]

The CA model is clearly broken, it is a chain that is too long with too many weak links. We have hundreds of root CA's, and combined with intermediate CA's, that number could be in the thousands. That is too many points of failure, which can bring down the entire system.

The following needs to be done immediately:

First: Eliminate Intermediate CA's:
If an entity does not qualify as a root CA, why should it be allowed to issue trusted certificates?

Second: Restrict Root CA'S by geography:
It is okay to trust the Chinese Post Office for *.cn, *.hk, etc. domains, why should we trust it for *.ca or *.com of Canadian companies? Why not restrict root CA's to geographic zones and also domain prefixes.

Three: Certificate Caching & Monitoring Should be built into browsers:
Certificate Patrol is an excellent addon that does this, why isn't it built into browsers? https://addons.mozilla.org/en-US/firefox/addon/certificate-patrol/