« previous 1 2 3 4 5 6 next »

DSA and ECDSA signatures

Digital signatures based on the DSA method (Digital Signature Algorithm) and the ECDSA method (Elliptic Curve Digital Signature Algorithm) require a random number that the signature creator has to keep secret in addition to the actual signature key each time a signature is created. If an attacker knows this random number, he can use the signature to guess the DSA or ECC key used.

DSA and ECDSA signatures are also vulnerable if predictable random numbers are used

This aspect is why OpenSSH DSA keys, which should be secure, have to be viewed as compromised if they are used in communication with an insecure Debian system for DSA public key authentication. If there are records of such an SSH session, the secret DSA key can be reconstructed from it.

X.509 certificates

OpenSSH uses 35 as a public exponent when creating keys, whereas the OpenSSL command uses the exponent 65537 to create an RSA key. The test program published by Debian, dowkd.pl, therefore cannot check any X.509 keys. However, the openssl-blacklist package created for Ubuntu Linux contains all additional blacklists and can therefore be used to test OpenSSL keys. It is also now available as a Debian backport.

In general, what is true for OpenSSL is true for OpenSSH: key material created with a vulnerable Debian system is weak and should be considered cracked. Issuing CAs should block affected certificates immediately and issue new ones. All TLS/SSL-protected servers – such as web servers and servers that use the STARTTLS protocol command, such as SMTPS-enabled MTAs and mail servers with POP3S or IMAPS – should also be checked to see if they contain any vulnerable key material.

Web server certificates based on unsafe keys are probably fairly common at the moment. A few sample checks on the Internet revealed weak keys on a number of servers. Attackers can guess at the private key for such Web servers and use the key to create a certificate for their own servers. It is also quite easy to tap communication with the original server that is encrypted with TLS/SSL. The network analysis tool Wireshark can decrypt SSL communication if it has the private key.

In particular, original web server certificates are worth their weight in gold for phishers and pharmers if they include the associated private keys. If a phisher manages to redirect victims to his own web site by means of pharming, DNS spoofing, or forged host entries, the victims do not even recognise they are under attack. Their browsers display that the server's security certificate matches the URI entered and was issued by a trusted CA.

This aspect will lead to considerable problems at some point because current browsers do not pay enough attention to blocking certificates. By default, many browsers fail to check the validity of server certificates; they therefore do not detect when a CA has revoked a certificate in its Certification Revocation List (CRL). Those who want to be on the safe side should activate inspections of CRLs in their browser settings.

Otherwise, attackers will be able to use a blocked certificate until that certificate expires. Most browsers will accept it without further ado. It would help if the browser checked which certificates are blocked via OCSP (Online Certificate Status Protocol). While most browsers now support OCSP, the function is generally disabled under default settings. To make things worse, not all CAs support the protocol.

The root

The worst case would be if a Certificate Authority (CA) used vulnerable certificates to sign certificates. In an initial test, all CA certificates provided by Microsoft and Firefox with a length of 1024 or 2048 bits and a public exponent of 65537 proved not to be vulnerable, so that major public CAs should not expect any direct problems. But companies and organisations that have created their own PKIs on a vulnerable Debian Linux with OpenSSL may indeed have problems, and operators could be forced to recreate their entire PKI.

« previous 1 2 3 4 5 6 next »