rsa

14 Articles

Hacking An IP Camera To Run Your Own Software

July 17, 2024 by 18 Comments

Ah, generic unbranded IP cameras. Safe, secure? Probably not. [Alex] has been hacking around with one of his very own, and he’s recently busted the thing wide open.

Determining that the camera had a software update function built in, [Alex] saw an opening for hijinks. The first issue was that the camera only accepts encrypted update packages, which complicates things somewhat. However, through some smart reverse engineering, the format of the updates and their encryption method became obvious to [Alex]. Oh, and partly because there was a GitHub repository online featuring the source code used by the manufacturer to encrypt their updates. That definitely helped. It also led [Alex] to suspect the manufacturer may not have properly respected the open source license of some of the routines involved.

In the demo of the exploit, [Alex] has the camera reach out to www.pudim.com.br instead of the servers of the original manufacturer. That’s a pretty clear way to show that the camera has been owned.

We first featured [Alex]’s work in this space all the way back in 2019. It’s come a long way since then!

Continue reading “Hacking An IP Camera To Run Your Own Software” →

Undo Arduino Encryption With An Oscilloscope

July 14, 2024 by 16 Comments

Cryptography ain’t easy. Seemingly small details like how many times a computationally intensive loop runs can give the game away. [Lord Feistel] gives us a demo of how this could work with nothing more than poorly designed code, a resistor, and an oscilloscope.

The hardware side is, as mentioned, really simple. Put a resistor inline with the Arduino and monitor the voltage drop across the resistor with the scope. When the chip is working hard, it consumes more current, and code sections that take longer will show up as longer dips.

On the software end, it’s only a little more complicated.  The RSA encryption scheme involves a lot of exponentiation and modulo-taking. Here, [Lord Feistel] is targeting a naive way of computing the exponents quickly, and demonstrates how you can read the exponent straight out the chip’s power demand.

Implementing this attack against a real-world RSA algorithm, in the context of the Arduino doing other stuff, will be harder. And we don’t know if the algorithm implemented in “standard” Arduino libraries is smarter than this one. (If you know, let us know in the comments.) But still, this is a cool example of just how simple and straightforward it can be to eavesdrop on bad code.

If you only need to bypass encryption instead of breaking it, check out [Lord Feistel]’s other tutorial on power glitching that we featured previously. If you haven’t played around with the hardware side of security, it gets deep pretty quickly, but you can at least dip your toes in the shallow end with what you’ve got in your closet.

This Week In Security: SSH, FTP, And Reptar

November 17, 2023 by 3 Comments

It’s time to strap on our propeller beanies, because we’re going to talk crypto. The short version is that some SSH handshakes can expose enough information for a third party to obtain the host’s private signing key. That key is the one that confirms you are connecting to the SSH server you think you are, and if the key validation fails, you get a big warning:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!

The math that makes this warning work is public-private key cryptography. The problem we’re talking about today only shows up in RSA authentication. Specifically those that use the Chinese Remainder Theorem (CRT) to quickly calculate the modulos needed to generate the cryptographic signature. If something goes wrong during that calculation, you end up with a signature that is mathematically related to the secret key in a different way than intended. The important point is that knowing this extra value *significantly* weakens the security of the secret key.

This attack has been known for quite some time, but the research has been aimed at causing the calculation fault through power vaults or even memory attacks like Rowhammer. There has also been progress on using a lattice attack against captured handshakes, to make the attack practical with less known information. The real novel element of this week’s approach (pdf) is that it has been tested against SSH.

The paper’s authors performed weekly scans of the entire IPv4 public network space, capturing the handshake from any listening SSH server, and also had 5 years of historic data to draw from. And the results are mixed. There is a Cisco SSH server string that is extremely common in the dataset, and only once did one of these machines send a miscalculated handshake. Possibly a random ram bit flip to blame. And on the other hand, the string “SSH-2.0-Zyxel SSH server” had so many bad signatures, it suggests a device that *always* sends a miscalculated signature. Continue reading “This Week In Security: SSH, FTP, And Reptar” →

Screenshot of the RSA calculator, showing the fields that you can fill into and the results as they propagate through the calculation

Lift The Veil On RSA With This RSA Calculator

July 8, 2022 by 2 Comments

Encryption algorithms can be intimidating to approach, what’s with all the math involved. However, once you start digging into them, you can break the math apart into smaller steps, and get a feel of what goes into encryption being the modern-day magic we take for granted. Today, [Henry Schmale] writes to us about his small contribution to making cryptography easier to understand – lifting the veil on the RSA asymmetric encryption technique through an RSA calculator.

With [Henry]’s calculator, you can only encrypt and decrypt a single integer, but you’re able to view each individual step of an RSA calculation as you do so. If you want to understand what makes RSA and other similar algorithms tick, this site is an excellent starting point. Now, this is not something you should use when roll your crypto implementations – as cryptographers say in unison, writing your own crypto from scratch is extremely inadvisable. [Henry] does say that this calculator could be useful for CTF players, for instance, but it’s also undeniably an accessible learning tool for any hacker out there wishing to understand what goes on under the wraps of the libraries we use.

In modern day, cryptography is instrumental to protecting our freedoms, and it’s a joy to see people work towards explaining the algorithms used. The cryptography tools we use day-to-day are also highly valuable targets for governments and intelligence agencies, willing to go to great lengths to subvert our communication security – so it’s even more important that we get acquianted with the tools that protect us. After all, it only takes a piece of paper to encrypt your communications with someone.

Understanding Elliptic Curve Cryptography And Embedded Security

July 4, 2019 by 26 Comments

We all know the usual jokes about the ‘S’ in ‘IoT’ standing for ‘Security’. It’s hardly a secret that security in embedded, networked devices (‘IoT devices’) is all too often a last-minute task that gets left to whichever intern was unfortunate enough to walk first into the office that day. Inspired by this situation, All About Circuits is publishing a series of articles on embedded security, with a strong focus on network security.

In addition to the primer article, so far they have covered the Diffie-Hellman exchange (using prime numbers, exponentiation and modular arithmetic) and the evolution of this exchange using elliptic curve cryptography (ECC) which prevents anyone from brute-forcing the key. Barring any quantum computers, naturally. All three articles should be understandable by anyone, with a simple, step-by-step format.

The upcoming articles will cover implementing security on microcontrollers specifically.  For those who cannot wait to learn more, Wikipedia has a number of articles on the topic of Elliptic Curve Cryptography (comparing it to the more older and still very common RSA encryption) specifically, as well as the Elliptic-Curve Diffie-Hellman key agreement protocol as discussed in the All About Circuits article.

A detail of note here is that the hardest problem in secure communications isn’t to keep the communications going, but to securely exchange the keys in the first place. That’s why a much much computationally expensive key exchange scheme using an asymmetric (or public-key) cryptography scheme  is generally used to set up the second part of the communications, which would use a much faster symmetric-key cryptography scheme, where both parties have the means to decode and encode messages using the same private key.

All the math aside, one does have to wonder about how one might denote ‘secure’ IoT. Somehow ‘SIoT’ doesn’t feel very catchy.

RSA Encryption Cracked Easily (Sometimes)

January 16, 2019 by 32 Comments

A large chunk of the global economy now rests on public key cryptography. We generally agree that with long enough keys, it is infeasible to crack things encoded that way. Until such time as it isn’t, that is. Researchers published a paper a few years ago where they cracked a large number of keys in a very short amount of time. It doesn’t work on any key, as you’ll see in a bit, but here’s the interesting part: they used an undescribed algorithm to crack the codes in a very short amount of time on a single-core computer. This piqued [William Kuszmaul’s] interest and he found some follow up papers that revealed the algorithms in question. You can read his analysis, and decide for yourself how badly this compromises common algorithms.

The basis for public key cryptography is that you multiply two large prime numbers to form a product and post it publicly. Because it is computationally difficult to find prime factors of large numbers, this is reasonably secure because it is difficult to find those prime numbers that are selected randomly.

However, the random selection leads to an unusual attack. Public keys, by their very nature, are available all over the Internet. Most of them were generated with the same algorithm and random number generation isn’t actually totally random. That means some keys share prime factors and finding a common factor between two numbers isn’t nearly as difficult.

Continue reading “RSA Encryption Cracked Easily (Sometimes)” →

Bad RSA Library Leaves Millions Of Keys Vulnerable

October 17, 2017 by 20 Comments

So, erm… good news everyone! A vulnerability has been found in a software library responsible for generating RSA key pairs used in hardware chips manufactured by Infineon Technologies AG. The vulnerability, dubbed ROCA, allows for an attacker, via a Coppersmith’s attack, to compute the private key starting with nothing more than the public key, which pretty much defeats the purpose of asymmetric encryption altogether.

Affected hardware includes cryptographic smart cards, security tokens, and other secure hardware chips produced by Infineon Technologies AG. The library with the vulnerability is also integrated in authentication, signature, and encryption tokens of other vendors and chips used for Trusted Boot of operating systems. Major vendors including Microsoft, Google, HP, Lenovo, and Fujitsu already released software updates and guidelines for mitigation.

The researchers found and analysed vulnerable keys in various domains including electronic citizen documents (750,000 Estonian identity cards), authentication tokens, trusted boot devices, software package signing, TLS/HTTPS keys and PGP. The currently confirmed number of vulnerable keys found is about 760,000 but could be up to two to three orders of magnitude higher.

Devices dating back to at least 2012 are affected, despite being NIST FIPS 140-2 and CC EAL 5+ certified.. The vulnerable chips were not necessarily sold directly by Infineon Technologies AG, as the chips can be embedded inside devices of other manufacturers.

Continue reading “Bad RSA Library Leaves Millions Of Keys Vulnerable” →