Embedded device security is a challenge that requires multiple routes of attack. You need to protect potentially sensitive data being transmitted over sometimes unsecured networks using the best encryption methods available, all while operating under memory and resource constraints.
"I believe that, for all devices you put on a network, you need to have some way of keeping people out of it," says John Safranek, Senior Engineer with wolfSSL. "And it’s surprising how easy it is to get on someone’s network."
wolfSSH is an addition to the embedded security landscape's suite of tools, offering a straightforward way for embedded systems users and designers to secure connections to their devices while taking advantage of cryptographic algorithms such as ECC.
AAC got the chance to ask Safranek about SSH, cryptography, and the difference between
What Is SSH? What Does It Offer Embedded Security?
Among the most useful tools in the networked world is Secure Shell (SSH). SSH is the successor of Telnet and is a cryptographic protocol used to secure two services on a network. It operates as a client-server pair, securing the connection, allowing user log-in, and then becomes the facilitator of remote command-line operations. Client authentication can be either username/password, or public key-based.
"In my past, [I was] working with machines using serial ports for logging and other control. Getting to work on SSH and being able to make that more secure has been exciting for me…but I’m also kind of a nerd into that sort of thing," Safranek tells AAC. "I see there’s a need for SSH in the embedded world."
Safranek goes on to describe some of his previous work involving radio equipment. "A lot of that stuff goes up on mountain tops and you’d have to send someone up to reconfigure or pull logs. With an SSH connection, as part of your setup, you could have a network connection and you don’t have to go to the mountain top to pull logs. I think that’s a useful thing to do with it."
That’s where he envisions wolfSSH coming in. wolfSSH is one of the newest open-source libraries added to the wolfSSL's suite. It includes support for SSH v2.0, has a footprint of 33kB, and a runtime memory usage of 1.4 and 2 kB. It contributes to wolfSSL’s mandate of creating security libraries for embedded systems that are lightweight, speedy, and secure.
"[It works with, at minimum, on] 16-bit devices—so your usual ARM, Microchip, PIC-32, pretty much if wolfCrypt runs on it, wolfSSH runs on it. It’s small, it doesn’t require pipes or multiple threads. It can run on a single thread in a time-constrained environment," says Safranek.
Cryptography for Embedded Security: ECC vs. RSA
What makes wolfSSH particularly interesting is its support for Elliptic Curve Cryptography (ECC). This is set in contrast to a more common and familiar public key cryptosystem, RSA (Rivest-Shamir-Adleman), which has been around since the late 1970s.
As Safranek explains it, there are pros and cons to utilizing either cryptosystem.
"For the longest time, we’ve been using RSA for public key cryptography and it uses a fairly simple math function that exponentiates to do its cryptography, but you need incredibly large keys with it. ECC uses a different math function that lets you use a much smaller key to get the same level of security as a larger RSA key," he says.
"A 2048-bit RSA key and a 256-bit ECC key have roughly the same security strength. So, it requires less memory: less storage to keep the keys and less memory to do the math. The math is more complicated, but the ECC code is just a little bit bigger than the RSA code, and it takes roughly the same amount of time—but it gives you the same bang for your buck for fewer bits."
"The math is more complicated, but the ECC code...takes roughly the same amount of time—but it gives you the same bang for your buck for fewer bits."
Cryptographic methods rely on mathematics that is generally near impossible to reasonably guess the solution to. RSA, for example, takes advantage of the difficulty of factoring large prime numbers. However, increasing security of the legacy RSA cryptographic algorithm also requires larger key sizes.
For ECC, the difficulty comes from the "elliptic curve discrete logarithmic problem," which permits the use of smaller keys. The formula for an elliptic curve is y2 = x3 + ax + b, and to avoid singular points (points where the curves of the line cross each other), the restriction 4a³ + 27b² ≠ 0 is applied.
When you add two points on this curve together, you can get a third number that is also on the curve by finding the point that is crossed by the line connecting the two other points, and then reflecting it over the x-axis. That is, P + Q = R.
Image courtesy of Hackernoon.
In cryptography, the elliptical curve is also described over a finite field, using y² mod p = (x³ + ax + b) mod p, where p is a prime number. This, combined with the point addition property, n•P+r•P = (n+r)•P, gives us the opportunity to select x as our private key, and y as our public key.
Knowing only the public key, there is no known algorithm that can solve this problem in logarithmic time, making it ideal for cryptographic purposes.
Image courtesy of Hackernoon.
wolfSSH uses ECC Diffie-Hellman and ECC Digital Signature Algorithm with elliptic curves NISTP256, NISTP384, NISTP521, Curve25519, and Ed25519. wolfSSH’s library requires about 32-bytes overhead to encrypt, meaning that the larger your message, the more negligible that overhead is.
If all this math talk concerns you, worry not, as Safranek assures AAC: "I think someone could get by with qualitative knowledge of cryptography without delving into the math. I don’t think you have to have a deep knowledge to use this."
Could Someone Crack wolfSSH's Encryption like Turing Cracked Enigma?
Taking a look back at history, one of the most important elements that led to Turing's eventual decryption of the Enigma code in World War II was the predictability and knowledge of certain messages, such as daily weather reports.
Could such a method be similarly used to intercept an encrypted message over wolfSSH, if you knew some of the contents?
"No, [and that’s because of] the initialization vector," says Safranek, "Every connection you make generates new session keys. So, typically, for one file if you knew part of it you would still have trouble because everything is dependent on the data before it and the initialization vector kind of skews the ability for predictions," he explains.
"[For example], in CBC mode, you are not just encrypting the data, you are stirring the previous block of data with the current block of data, and then encrypting it. So even if you know [the data is] like a Word document and the first several bytes are always the same in a Word document, you still can’t pull the next chunk out. There’s just enough transform and change between chunks of data that you shouldn’t be able to decrypt it."
Thank you, John, for your time!
What questions would you ask a cryptography expert if you could? Share your curiosities in the comments below.