Elliptic Curve Digital Signature Algorithm, or ECDSA, is one of the more complex public key cryptography encryption algorithms. Keys are generated via elliptic curve cryptography that are smaller than the average keys generated by digital signing algorithms. Elliptic curve cryptography is a form of public key cryptography which is based on the algebraic structure of elliptic curves over finite fields. Elliptic curve cryptography is mainly used for the creation of pseudo-random numbers, digital signatures, and more. A digital signature is an authentication method used where a public key pair and a digital certificate are used as a signature to verify the identity of a recipient or sender of information.
What is ECDSA?
ECDSA does the same thing as any other digital signing signature, but more efficiently. This is due to ECDSA’s use of smaller keys to create the same level of security as any other digital signature algorithm. ECDSA is used to create ECDSA certificates, which is a type of electronic document used for authentication of the owner of the certificate. Certificates contain information about the key used to create the certificate, information about the owner of the certificate, and the signature of the issuer of the certificate, who is a verified trusted entity. This trusted issuer is normally a certificate authority which also has a signed certificate, which can be traced back through the chain of trust to the original issuing certificate authority.
The way ECDSA works is an elliptic curve is that an elliptic curve is analyzed, and a point on the curve is selected. That point is multiplied by another number, thus creating a new point on the curve. The new point on the curve is very difficult to find, even with the original point at your disposal. The complexity of ECDSA means that ECDSA is more secure against current methods of encryption cracking encryptions. Along with being more secure against current attack methods, ECDSA also offers a variety of other benefits as well.
The Benefits and Drawbacks to using ECDSA
A benefit to using ECDSA over other public key cryptography is how new ECDSA is. ECDSA was standardized in 2005, compared to most common public key cryptography algorithm used, RSA, which was standardized in 1995. Since ECDSA has been around for such a shorter period of time, hackers have had less time to learn how to crack ECDSA. This, along with ECDSA’s complexity make switching to ECDSA look like a more desirable option each year. These benefits are why newer protocols choose to use ECDSA over RSA for public key cryptography functions.
Yet, RSA is still the most widely used public key cryptography method. This is due to the length of time RSA has been around, among other reasons. Though attackers have had more time to crack RSA, it is still the tried and true method used all across the Internet for digital signing, SSL/TLS transport, and more. A drawback of ECDSA is that it is complex to implement, whereas RSA is more easily set-up in comparison. The simplicity of RSA is often a draw to organizations, as it offer less roadblocks in its set-up. The downfall of many different organizations using ECDSA that have been hacked is the improper implementation of ECDSA itself, as it is complex to implement in the first place.
Where can ECDSA be implemented?
ECDSA does not just need to be used in the signing of certificates, it can be used anywhere RSA has been with the same effect in the end. Public key cryptography methods are found in everything from TLS/SSL to code signing. The government uses ECDSA to protect internal communications, while Tor uses it to maintain anonymity for their users. These are just a few of the uses ECDSA can be used for, but all cryptosystems face an issue with the emergence of quantum computing. Quantum computing threatens to make all classic cryptosystems, from AES to RSA to ECDSA, obsolete. The methods used in quantum computing mean previously strong methods like ECDSA will need to update to use quantum cryptography, or become obsolete.
Secure Socket Shell (SSH), also known as Secure Shell, for convenience, is a popular protocol that operates on the principle of public key cryptography. Primarily used to secure private transactions, they are leveraged to institute authentication on both the server-side and client-side. It is important to note that the Secure Shell is used to encrypt data flowing to and from a remote system. Some typical use-cases of this kind of cryptography include system-to-system file transfers, remote logins into computer systems, and automated server access without having to manually log in.
One of the biggest benefits of SSH Keys is their resilience against cyber exploits, such as brute-force attacks, given that passwords are not required to be exposed over the web in the transaction. It also features most of the key capabilities of PKI and fundamentally works on the principle of public-private key pairs.
To the uninitiated, SSH Keys and x.509 certificate-based authentication (which also involves public and private keys) might seem similar, but in truth, they could not be any more different.
SSH Keys vs x.509 Certificates – Key Differences:
While x.509 certificates rely on digital certificates and issuing bodies (Certificate Authorities) to sign private keys, SSH Keys are not governed by any institution. They are created, circulated, and used within transacting partners and organizations, and can be managed without any external interference.
That aside, they also possess functionality that their counterparts don’t – the ability to enable remote access to systems. On the other hand, TLS certificates cannot provide that sort of functionality on its own, unless deployed alongside other protocols like FTP.
Risks associated with SSH Keys:
The absence of a governing body presents a veritable challenge in managing SSH keys – a lack of organization. SSH Keys are generated based on need, and when ad-hoc processes govern the issuance of these keys, there’s bound to be key sprawl. This means keys are discarded once they are declared useless or vulnerable, and a lack of inventory renders them difficult to keep an eye on – considering the fact that large organizations may possess hundreds of thousands of SSH keys on file. However, their presence on the server makes them possible back-doors to potential hackers, which can then be abused to conduct data espionage, theft, or breaches.
Key rotation, another important function, is often ignored by administrators. A stale key presents a weak link to malicious actors, which can, again, be abused to exploit network resources.
SSH Key Management Best Practices:
If you do not possess organizational directives toward SSH key handling, it would be in your best interest to institute one now. Enforcing strict policy, exercising audit tracking, and possessing full control and visibility into the SSH key infrastructure can go a long way towards bettering the cyber health of the org. Automation of management is also an excellent way to do this – there are tools available that can actively manage and automate the entire SSH key lifecycle. In the meantime, here are some best practices you can start following immediately to take your cybersecurity up a notch.
Gain Complete Visibility:
Only by finding and locating the keys on your system can you protect them adequately. Run periodic discovery scans across your network with an appropriate tool to locate and inventory all SSH keys. Once this is done, map them with the endpoints they are tied to, and tag them with all the information an administrator would need while dealing with them, such as passcodes
Rotate Keys Regularly:
Stale SSH keys present a golden window of opportunity to hackers who may try to crack their passcodes and infiltrate the server. Set up policy that enforces regular generation, re-keying, and rotation of SSH keys, and ensure that all stakeholders are duly notified when this happens. Care must be taken NOT to reuse passcodes, and to use fresh credentials each time. Automating this process in large organizations can save several man-hours and significant operational costs.
Enforce Audit and Policy:
Create org-wide policy, and ensure that operations/IT personnel adhere to it – For instance, policies on regular key rotation. Furthermore, make liberal use of audit trails using specialized software, in line with industry regulations, to maintain tabs on the use, reuse, and application of all your SSH keys.
Create Role-based Permissions:
Prohibit access and modification of SSH Keys or their credentials by all the personnel in your team(s). Use directory services to provide different levels of privilege for each user category, to prevent haphazard control and promote audit trail.
Avoid the Use of Hard-coded Keys:
When SSH keys are built-into or packaged with software applications, they present a dangerous security vulnerability. Why? Since they’re governed by passphrases, a carelessly issued SSH key with a weak passphrase may be the weak link in an application that hackers could potentially exploit, compromising the integrity of the entire applications. Ensure that SSH keys are centrally managed by a dedicated management system.