Posted Ensuring compatibility without compromising security: the case of ECC/RSA hybrid certificates on Blog
We have talked a lot about ECC (Elliptic Curve Cryptography) for the past year. Although the use of elliptic curves is not exactly new, their use in our industry is fairly recent: ECC is a new cryptographic algorithm used for key exchange and authentication purposes in the SSL/TLS protocols (see this previous blog article for more details).
It is expected that RSA – the current standard - will be replaced by ECC as its scalability is becoming an issue with the arrival of IoT (Internet of Things): explosion in number of devices, machine to machine (M2M) communications, ever-growing amount of data transfers, etc.
We expected this change to happen. This is why Symantec’s ECC roots have been added to all major root stores back in 2007. Most CAs followed years later.
ECC, RSA and compatibility
The reliability and performances of ECC no longer need to be demonstrated. However, a significant obstacle to the adoption of ECC lies on the lack of support for this relatively new algorithm in legacy products. While all modern servers and browser fully support ECC, some legacy system will not trust ECC roots, or will not be able to support ECC at all.
Browser compatibility (root ubiquity) as of today
Current Server compatibility as of today
There are devices and systems that are unable to proceed with ECC due to a trust deficit due to the missing trusted ECC root certificate and it is not always possible to upgrade, change servers or switch to another application easily. To overcome this issue, Symantec has created a solution for devices and systems that can support ECC but don’t have ECC roots in their trust stores: hybrid ECC/RSA hybrid SSL certificates.
Hybrid certificates use ECC for encryption and authentication but are chained to a well-trusted RSA root. Hybrid ECC/RSA certificates enable you to benefit from the best protection for your current infrastructure and mitigate potential compatibility issues at the same time.
How does it work?
It’s fairly simple: when you enroll, we give you the choice between a full ECC certification chain (fig.1) and a hybrid ECC/RSA certification chain (fig.2). The full ECC chain comprises of your ECC SSL certificate, signed by an ECC intermediate, signed by an ECC root.
Fig. 1:full ECC chain
In order to offer hybrid RSA/ECC certificates, we have created a new ECC intermediate signed by an RSA root. This intermediate can be installed as direct intermediate, or as a cross certificate to a full ECC chain.
The direct intermediate is the solution we recommend. You benefit from ECC encryption for your infrastructure, while using a globally trusted RSA root.
Fig.2: hybrid ECC/RSA chain
If you are unsure which certification path is made for you, or if you have questions or concerns, please contact us! We are happy to help and to advise.
Mar 07 2018, 9:10 AM
Posted How the Private and Public Key Pair Works on Blog
Did you know this month was “couple appreciation month”? Let’s use this as an opportunity to explain in simple words how the security of an online transaction relies on a happy, inseparable couple: a public key and a private key.
Public keys and private keys are part of a general structure we call PKI – Public Key Infrastructure. The SSL and TLS protocols, which are globally used to secure not only websites, but also emails and web applications, are based on this structure. So we might as well say that there are thousands and thousands of public and private keys in operation right now around the world!
Keys are used in algorithms to encrypt and decrypt data. You may think the same key is used to encrypt and decrypt, but there’s a twist: there are algorithms in this world which are able to encrypt data with one key… and decrypt it only with the help of another key! Magical, isn’t it? (For those who don’t believe in magic, you can read more about trapdoor functions here). In the case of SSL, one key – the public key - is used to encrypt data; only the corresponding private key can decrypt it. What a lovely (and useful) couple.
In the SSL protocol, public keys and private keys are generated by servers. The private key remains locked and secure in the server, while the public key is pinned to the server’s SSL certificate. Whenever a browser connects to the server, the server sends its SSL certificate which contains the public key. The browser can then use this public key to encrypt data and send it to the server, which is now the only one able to decrypt such data thanks to its private key.
Both keys are inseparable, and of course each pair is unique: the public key belongs to its corresponding private key and only to this one.
Public and private keys are essential to the security of our exchanges. Thanks to them, we don’t have to worry about someone eavesdropping on our conversations. But there is still a major issue: what if a hacker intercepts the server’s public key, and sends their own public key instead?
What guarantees the browser that the public key received is actually the public key from the server it wanted to reach? This is why Certification Authorities like Symantec play an essential role: CAs authenticate servers and their public key through a unique document called the SSL certificate!
If you’re curious about SSL and more specifically about how SSL certificates work, you can find more
Mar 07 2018, 9:10 AM