Another high-profile issue is the use of Intel’s Visualization of Internal Signals Architecture (VISA) to monitor what other chips are doing, essentially giving a hacker a logic analyzer that he can use to probe the operation of other chips.
More recent examples include the rosenbridge backdoor, in which undocumented features of a microprocessor could let any application get root access for an operating system. Dobb's Journal even had the "Undocumented Corner," a column that described some of these. Such undocumented features are surprisingly common in hardware.
#Encrypto methods for future generator
To work around this issue, most, perhaps all, hardware that implements cryptography has a way to bypass the output of its random number generator and use known values in testing. If your inputs change every time you do a test, as they would if you were using random numbers, testing may be close to impossible. Testing something complicated is hard, and it's made even harder if you can’t test it with lots of known input-output pairs. If you're testing hardware that implements cryptography, using random values makes testing more difficult. Here's why it's so complicated, plus some tips to simplify testing cryptography-enabled software. That means that your cryptography isn't providing as much security as it could, and that's bad. If a key doesn't look just like random bits, it's possible for an attacker to guess it more easily. When you generate cryptographic keys, for example, you need to generate lots of random (actually pseudorandom) bits.
And it often uses random numbers for some of those calculations. It often does complicated calculations on multi-thousand-bit values. Today's cryptography isn’t easy to understand. But it's even harder when you're implementing cryptography. How do you test hundreds of millions of lines of code or tens of billions of transistors? It’s very hard.
0 kommentar(er)
