Slashdot Mirror

You are either ignorant or a liar. (Maybe a paid-for liar?). Just read this: https://plus.google.com/+Theod...

That is a few more people than "nobody". The flaw is that the whole design does not allow verification that it is non-compromised. The claim that including its bits in JTAG would be a security risk is completely bogus, as an attacker with access to the JTAG pins can do whatever they like already. With those bits in JTAG, it would be relatively easy to verify the analog-side is actually analog and is actually what feeds the whitener. That possibility was intentionally sabotaged, and the _only_ good reason for that is that they want to be able to compromise the CPRNG in select batches and make detection of that very hard. And no, there is no software access to those JTAG pins and yes, the hardware to query the internal CPRNG state and analog bit stream must be in place to test the CPU. That means they are switching this access explicitly off after they have verified the hardware works. So not only is this a compromised architecture and design, it is also more effort than doing it right. IT does not get more obvious than this.

Your link, BTW, is worthless. It does not go into the needed level of detail. The contrast with what you get for the VIA C3 generator (e.g.), is quite telling: http://www.cryptography.com/pu.... And VIA has a non-compromised design as they do not desperately try to hide what the analog random source spits out.

So while the tin-foil-hatters were all pointing their fingers at Intel, who provide a full cascade RNG that isn't weak, doesn't have a back door and has stood up to scrutiny, they weren't paying attention to the OS vendors who were getting it wrong despite the hardware available to them.

There have been other attacks previous discussed here as I recall, such as using power fluctuations or timing attacks, and so on, as cribs to retrieve a key. It appears this sort of attack that exploits the characteristics of the system performing the encryption will continue to be an attack vector of growing importance.

Timing Attacks on Implementations of Diffie-Hellman, RSA, DSS, and Other Systems

Abstract. By carefully measuring the amount of time required to perform private key operations, attackers may be able to find fixed Diffie-Hellman exponents, factor RSA keys, and break other cryptosystems. Against a vulnerable system, the attack is computationally inexpensive and often requires only known ciphertext. Actual systems are potentially at risk, including cryptographic tokens, network-based cryptosystems, and other applications where attackers can make reasonably accurate timing measurements. Techniques for preventing the attack for RSA and Diffie-Hellman are presented. Some cryptosystems will need to be revised to protect against the attack, and new protocols and algorithms may need to incorporate measures to prevent timing attacks.

Breaking DES with side-channel attacks

This lab will demonstrate how power analysis of cryptographic hardware can reveal the key. We will be using basic electronic measurement tools such as oscilloscopes to demonstrate this side-channel attack.

You will be using a small hardware board (fig. 1) with a generic microprocessor programmed to perform DES encryption and decryption. The scenario is that you are the attacker and want to find out the secret key stored inside the board. There is no way of getting to the key directly, so you will need to perform a side-channel attack by measuring the power consumption of the board while the algorithm is running. The hardware board also allows the user to load a custom key in order to compare the power consumption.

And to think that there were people poopooing NSA for pulling cables and servers that Snowden had access to. More attack vectors for everybody!

The technology inside Apple’s $50 Thunderbolt cable

A source within the telecom industry explained to Ars that active cables are commonly used at data rates above 5Gbps. These cables contain tiny chips at either end that are calibrated to the attenuation and dispersion properties of the wire between them. Compensating for these properties "greatly improves the signal-to-noise ratio" for high-bandwidth data transmission.

I don't believe the authors attacked the Ivy Bridge RNG in the way described. They described a way, they didn't do it.

Why?
1) They show a plot of a DFFR_X1. This is a normal D type flip flop you would find in synopsis libraries and many other libraries you would use in an SoC process. These are not the flops used in the Ivy Bridge DRNG. Also the plot was from a layout program, not a micrograph.

2) The proposed attack required an average of 2.1 billion attacks (fixing k and v until you hit the right CRC). I don't think we sold 2 billion Ivy Bridges to these guys. The alternative they propose is to try it in simulation first. Running 2 billion simulations of full BIST would take a while and they don't have the code. If they had the RTL code they would be proposing other attacks.

3) They don't identify the site of the attack on the chip. They don't know where the site is.

4) They don't show RdRand output of a compromised chip. This would be trivial.

The main message of the article is sound. There are physical attacks that are hard to see optically. But the attack they describe against Ivy Bridge is hypothetical, based on the information in the CRI audit paper here: http://www.cryptography.com/public/pdf/Intel_TRNG_Report_20120312.pdf

Well CRI audited it. Who else do you think is in the pocket of the NSA?
http://www.cryptography.com/public/pdf/Intel_TRNG_Report_20120312.pdf

That email chain is full of paranoid bullshit. I and one other person designed the random number generator hardware behind RdRand. It's not got any back doors. The NSA doesn't have one. I don't have one. It's been through audit by someone else who probably isn't in bed with the NSA: http://www.cryptography.com/public/pdf/Intel_TRNG_Report_20120312.pdf .

We built that RNG in order to stop the platform entropy problem that plagues computer crypto systems and to encourage others to do RNGs correctly. So by refusing to use the one reliable, built-for-security true random source of entropy in a processor and instead scrapping around with interrupt timing and disk head timing while claiming it is more secure is as stupid as it appears to be.

Most of the RNG chips publish pretty good specifications on the design of their entropy source, the amount of real entropy it provides, and the circumstances in which that entropy level might be reduced. There could be implementation or production errors or course, just like there could be runtime or compiler errors with software, but the design is available for perusal and has been analyzed.

For example, the Intel 82802:
http://www.cryptography.com/resources/whitepapers/IntelRNG.pdf

On 1 March 2005, Arjen Lenstra, Xiaoyun Wang, and Benne de Weger demonstrated[8] construction of two X.509 certificates with different public keys and the same MD5 hash, a demonstrably practical collision. The construction included private keys for both public keys. A few days later, Vlastimil Klima described[9] an improved algorithm, able to construct MD5 collisions in a few hours on a single notebook computer. On 18 March 2006, Klima published an algorithm[10] that can find a collision within one minute on a single notebook computer, using a method he calls tunneling.

If, on the other hand, you mean "get to a boot prompt", well, if grub is password protected, it won't allow you to read any file off the system either.

If you mean something else, please explain what...

check my MD5 signatures

What's the point, indeed. We should have moved away from MD5 signatures years ago. It's only a matter of time before some maliciously inclined asshat starts forging MD5 signatures on FLOSS packages, just to prove a point.

MD5 is broken and should not be used. It's time the FLOSS world went to at least SHA-224, if not SHA-512 (for future proofing, lots of bits). And just for reference, there is an open call for a new secure hash.

To bad they can't sue the guys who made AACS (since they're part of the consortium). I wonder if they'll be able to sue the people who developed BD+, once that gets owned.

Read what BD+ really is:
http://www.cryptography.com/technology/spdc/bluray .html

This means that each Blu-Ray disc has a computer program compiled to execute within a proprietary, secure VM. What this means is that each disc has a program built into it whose purpose is to boot, validate that it is running on licensed hardware, enforce security policy, and if those checks are met, extract a key from its own memory and play the content.

What does this mean for people attempting to defeat the security?

Well it means that a full crack of BD+ will require crackers to implement a virtual machine which acts in exactly the same way as the hardware VM would act. This represents a what I will casually call a "larger challenge" than defeating CSS or AACS, in which you have to decrypt a key or a list of keys. In this case, you have to come up with something which can determine the full dynamic runtime execution path of a static binary - a currently unsolved problem in Computer Science, despite numerous attempts to do such a thing by some of the world's brightest minds.

Just putting the same source code through a randomizing compiler/packer/obfuscator of the types that game companies have been working on for a while makes the challenge immensely harder. Precedent? http://spa.jssst.or.jp/summer-2005/paper/05046.pdf
There's too much to talk about.

And who's deployed this type of technology already? Who has a secure virtual machine with secure bytecode doing challenge-response to determine hardware legitimacy? People Who Care: a lot.

The other major problem is that the challenge-response authentication made by the program contained in the disc against the embedded hardware will require a "real" cert to succeed. Yes this is the TPCA/Palladium "sky is falling" scenario come to pass. Either the implementors made a cryptography implementation mistake, or someone with a scanning, tunneling electron microscope figures out how to defeat the epoxy guards and actually read the private cert material off a chip, or someone with a previously unheralded supercomputer or mathematical technique breaks the key from a known subset of challenge/response pairs... - or, it will remain unbroken. It is strong, known algorithm public key cryptography.

What's really interesting about all this is if someone DOES find a way to break BD+, there is really strong incentive for them to use it to break & release movies rather than release code which performs the break. Why? Get yourself a windows VM and download all the latest in DVD-breaking binaries: ripit4me, dvd decryptor-last, dvdshrink-last, etc. Then set windbg to be your default debugger, and start trying to break very recent DVD releases. What you'll find is that the entertainment company is employing people to literally find security holes in the input to the cracking tools - the dvd image itself, and then embed "exploits" into their dvd images. There is data on those discs that has no other purpose than to crash certain binaries. It becomes obvious once you trap execution in a debugger and know a little bit about x86 asm. Don't get me wrong, they're not executing arbitrary code, just causing a DoS - but that's only because they know they can't. Some of the conditions they've found and abused are CERTAINLY exploitable. But they also know that putting shellcode in their DVDs defeats plausible deniability, which is a hell of an asset.

Now push this knowledge forward to BD+. If someone actually manages to set up a "shim VM" that executes BD+ language and acts as a proxy between secure hardware and the bytecode, and RELEASES that VM, then we know the entertainment companies are going to enter a reverse engineering arms race. They're

I agree that DRM'ed music should sound no different, but let me play devil's advocate for a minute.

It might be possible that the decryption algorithm introduces some jitter by taking a varying amount of time to decrypt a chunk of data. A poorly-engineered system might pass this jitter through to the DAC, resulting in degraded audio quality. It might also be possible that the decryption operations cause the CPU to introduce additional noise on the power rails, which might also impact audio quality in a poorly-engineered system.

So, I don't think it's impossible that DRM affects sound quality. I'm just not convinced that it actually does.

Because that would require the hashed password and a preimage attack.

See here.

Summary for those who are lazy:

• This is a collision attack. The attacker will be able to find two messages that will produce the same hash, but the attacker cannot choose what the hash will be. So this rules out attacks on hashed passwords.
• Since a collision attack can find to messages that will produce the same hash, it is possible to use this to break message signing, such as DSA and RSA. where a hash of the message is generated first and then signed cryptographically.
• Collision attacks cannot be used to tamper with existing SSL certificates. It can be used to craft a CSR which will allow you to receive a server certificate with a collision to one containing a wildcard for the domain name and an expiration date far in the future. This by far is one of the most dangerous exploits because most CA's will issue certificates without completely verifying the identity of the requester.
• Because of the way MD5 is used in SSL 3.0/TLS, these attacks do not affect it.
• Collision attacks do not affect MD5 and SHA-1 when they are used in an HMAC. So even though a hash function can be broken by either by collision attacks, they can still be used safely in HMAC.
• Tampering a signed binary is only possible using a preimage attack.
• All will have naturally collisions. How exploitable they are depends on how easy it is to find those collisions.

In conclusion, the value of this attack/exploit is only relative to how the hash function is used in an application. Just because this exploit and source code for it exists, that does not that these hashing algorithms are completely useless.

http://www.cryptography.com/cnews/hash.html
http://www.nsrl.nist.gov/collision.html

One of the original smart card hacks was done by Ben Jun, Paul Kocher, and Joshua Jaffe, the guys at Cryptography Research, using a technique called "Differential Power Analysis" which they did with a $50 HP oscilliscope to extract the private key stored on a smart card. You can find the white paper here.

One of the original smart card hacks was done by Ben Jun, Paul Kocher, and Joshua Jaffe, the guys at Cryptography Research, using a technique called "Differential Power Analysis" which they did with a $50 HP oscilliscope to extract the private key stored on a smart card. You can find the white paper here.

I may be wrong but I think that for that purpose, the use of MD5 is still quite secure. What those researchers did was make 2 files with the same MD5, they didn't choose the md5 value itself. In order to crack the schemes you're mentioning the md5 value is a given value for which you want to generate another file (many times with the additional restriction that the file sizes must match).

Read about collision attacks versus preimage attacks here.

Unless you're assuming that at least one of the people responsible for redistributing the software have bad intentions?

Quoting from the linked page:

Q: What is a collision attack and a preimage attack?
A: A preimage attack would enable someone to find an input message that causes a hash function to produce a particular output. In contrast, a collision attack finds two messages with the same hash, but the attacker can't pick what the hash will be. The attacks announced at CRYPTO 2004 are collision attacks, not preimage attacks.

Unless they have lots of supercomputer time, seeding the occasional p2p file with bad data will be very expensive.

HD disc security requirements and AACSLA

No, that would be a preimage attack (read the FAQ). The md5sum attack is a collision attack: you can create two files that have the same md5sum, but you can't specify either of the two files in advance.

I found this technical overview of SPDC that explains this and other things.

The question-and-answer section on this page are certainly informative. It looks like the security technology will be self-updating so that after a particular player's key is gained and resultant piracy detected, future HD-DVDs will not play on that model.

There are a lot of states SYSTEM REQUIREMENTS to address that problem.

However, at no point (that I could detect) does the Q&A bring up a SYSTEM REQUIREMENT for the following scenario: What happens to legitimate purchasers of a given player that gets hacked, and therefore locked out, by somebody else?

In other words, is the locking out of particular players specific to a particular player (by serial number or whatever) thereby locking out only one person, or does the entire set of like models get locked out thereby locking out everyone who purchased that model?

I'd point people here first, then to a few other links that other people have pointed out. The article linked is a bit terse for a newbie.

MD5 is still safe for the purpose of file digests. The methods published do not allow the attacker to find a collision for a given digest value. Check this FAQ for some details.

You're absolutely right. Except for the "very hard" part.

It costs about a hundred bucks to buy a good (secure) random number generator. Noisy diodes, for instance, work great. Hell, taking photos of lava lamps works, too.

QRNG

SafeXcel

VIA C3 RNG

I, Bob, agree to pay Charlie $ 5000.00 on 4/12/2005.

I, Bob, agree to pay Charlie $18542841.54 on 9/27/2012.

4d4f44971dc6b71171c01abf5cbc7593

269a931c35a592458ad96e768e5f9d37

Security is a system problem, and requires you to look beyond the boundaries of software.

Breaking security requires to find a side-channel, where secure information leaks through. Just when you thought you found the perfect software solution, there's some chap that starts probing your address bus or checking the power consumption profile of your processor. Darn!

If you go to the site of the DPA attack,Cryptographic Research, you can see that they have already have patents on Systems to protect against these kind of attacks. So it's not like they have developed anything (I don't know if they have) but you can already pay them to get protection from this kind of attack! yay!

Granted you can use the readers with "glitching" circuitry to program normal legal cards but its hard to argue that a device with special circuitry to bypass tamper resistance is for any other purpose than the illegal one when for much cheaper you can get a normal writer that will achieve the legal results.

Other than actually testing vendor claims that their smartcard products are not vulrenable to glitching, and other well known attacks (see Cryptography Research)

It's sad to see civil libertarians like Felten and the EFF jumping on the mandatory licensing bandwagon. Few policies could be as unfair, misguided and unimplementable.

Mandatory licensing is unfair because people are forced to pay a fee even if they don't take advantage of what they are paying for. Everyone would be paying for music and movies and whatever other content people start pirating, even if they don't partake of those sources of entertainment.

(This is assuming that everyone is charged this "content tax" just to use the net. If we try to inspect what people download to see if it's music, etc., that just raises enormously more problematic issues in terms of privacy, restrictions on encryption, and a host of other negative consequences.)

Mandatory licensing is misguided because it throws in the towel prematurely. We don't know, yet, whether technological means for protecting content are going to succeed. The situation is still in flux, with proposals like Palladium and DRM, or the new ideas from Cryptography Research still offering the potential for letting content producers get paid.

Mandatory licensing is unimplementable because there is no way to fairly divide up the funds. Realize that the amount of money raised by the modem tax, excuse me, the content tax, would have to be comparable in size to the combined revenues of the music, movie, game and software industries, if we accept that those goods are all going to be pirated and this tax will replace their current sources of funding. We're talking probably $50 billion or more. What do you think is going to happen when you put that pot of money on the table and try to allocate it based on how many times things get downloaded?

People are going to cheat! They'll build all kinds of download bots and use other methods to get their statistics inflated. It's hard enough to measure popularity today; once you have tens of billions of dollars riding on the outcome it's going to be impossible.

That's one thing markets are good at: by making people pay for what they get, they reveal very clearly which items are worth more to the public than others. Trying to replicate this information service using some kind of polling or sampling of downloads is not only going to be invasive, it is just not going to work.

I wish we could nip this stupid idea in the bud, but apparently it is the best the "freedom" community can do. Taxing net users so the government can subsidize the arts is the worst possible solution to our problem.

I believe Paul Kocher first proposed (this is PDF) this attack way, way back in 1995, and as I recall, he even applied it to networked systems. RSA Labs' BSAFE, since version 3.0 has included a "blinding factor" in its RSA implementation that renders this attack ineffective. Reading the original RSA Labs bulletin (also PDF) on this attack shows a very simple fix, and I'm surprised that this hasn't made its way into OpenSSL! Ron Rivest proposed this back in early 1996. What's up?

Differential power attacks require physical proximity and are not useful over the internet. See this page(on his site) for more details

DES hasn't been cracked per-se but the 40bit keyspace can be scanned very efficiently now with distributed computing and specialized hardware.

• Distributed.net (40 days)
• Deep Crack(56 hrs)
• EFF(22 hrs)

Differential Power Analysis and even Simple Power Analysis (SPA) can be used on a smart card.

Or Europe based web sites having to comply with the narrow laws (concerning e.g. nudity, drugs, or cryptography) of hyporcrite US.

Why did Kerchkhoff made such a radical statement? Because over the last, oh roughly 500 years, history has told the sad tale of bold cryptographers who sold their systems as unbreakable, and grossly underestimated the inventiveness of their enemies.

Ciphers (encryption algorithms) need to be designed to withstand the most cunning of oppositions. Who's main method is thinking "out of the box" to come up with diffierental cryptanalysis, timing attacks -- timing how long an encryption takes, differential power analysis -- measuring the power consumption, impossible cryptanalysis -- figuring which differentials aren't possible).

Bruce Schneier at Counterpane Labs and Ross Anderson at Security Group at Cambridge University have several essays about how security systems fail because the enemy "breaks the rules". (Why Cryptosystems Fail, Why Cryptography Is Harder Than It Looks, etc.)

To understand more about how "security through obsurity" does more harm than good, read any one of the dozen accounts about the Engima used during World War II, and the Anglo-American (and Polish) effort which successfully analysed this "unbreakable" system. Like Code Breaking, The Code Breakers, or The Code Book.

Why did Kerchkhoff made such a radical statement? Because over the last, oh roughly 500 years, history has told the sad tale of bold cryptographers who sold their systems as unbreakable, and grossly underestimated the inventiveness of their enemies.

Ciphers (encryption algorithms) need to be designed to withstand the most cunning of oppositions. Who's main method is thinking "out of the box" to come up with diffierental cryptanalysis, timing attacks -- timing how long an encryption takes, differential power analysis -- measuring the power consumption, impossible cryptanalysis -- figuring which differentials aren't possible).

Bruce Schneier at Counterpane Labs and Ross Anderson at Security Group at Cambridge University have several essays about how security systems fail because the enemy "breaks the rules". (Why Cryptosystems Fail, Why Cryptography Is Harder Than It Looks, etc.)

To understand more about how "security through obsurity" does more harm than good, read any one of the dozen accounts about the Engima used during World War II, and the Anglo-American (and Polish) effort which successfully analysed this "unbreakable" system. Like Code Breaking, The Code Breakers, or The Code Book.

There was already a Word marco virus Caligula that attacked the PGP secret keyring and mails it to codebreakers.org, circa 1998.

You are mainly concerned with your private key ring, since lose or corruption of that would be the most damage. If the public key ring was modified you could alter local trust of a specified key, but it could not sign a public key without the private key.

As others have stated the private key itself is protected by symmetric encryption (e.g. IDEA, TripleDES) and you need the passphrase to unencrypt this encryption. So, a private key protected by a poor passphrase could be brute forced using a fast dictonary search tool, similar to Alex Muffett's crack for Unix passwords.

There are several ways to increase the security without irrating the user, such as using a floppy based key ring, using a smartcard memory card to store your own public/private keys, using a Dallas iButton, a removable PCCard (PCMCIA) storage device, or using a crypto smart card that stores your own private/public key, and does the RSA calculations on the card, designed in a such a manner as the keys cannot be extracted from the card. This gets into Differential Power Analysis (PDA) and tamper resistance attacks.

For a high security application, you could consider a hybrid smartcard and PDA (e.g. Palm), which forms a small trusted computer. Of course most security experts wouldn't call a out of the box Palm and PalmOS a trusted platform, but it's an example of a smartcard with a direct human interface (human input & output), rather than trusting a larger more complicated computer which is also more flexible because it is designed to be general purpose. Some 3G cell phones plan on having similar smartcard interfaces I believe. I think Nokia had a prototype. Of course since there have been some trojan SMS messages already seen in Europe, and with WAP expected to expand its capabilities rather than die, you can expect this to be a more virus friendly platform as cellphones evolve.

While Bruce's Secrets and Lies shows his change of heart from the absolute security through cryptography that he and cypherpunks dreamt of in the early 90's, he now understands that absolute security in a practial system is a myth, and wants readers to think like engineers in weighing of trade-offs, how easy to use verus how secure, and how expensive vs. how secure. It is not a reason to give up on cryptography, but to realise that in designing and working with secure systems you need to look at more than just which neat cryptographic algorithms to use.

I was at work one Sunday morning a few years ago when the husband of the receptionist was there too; looking at a long strip chart; it must have been twenty feet long. When I asked what it was, he said that it was the fourier transform of the power line into a facility that he believed was using centrifuges to separate U235 from U238.

Power analysis is one of a whole class of interesting attacks on secure facilities and devices. These side channel attacks are really powerful because they sidestep a whole host of common security assumptions. TEMPEST, of course, is another side-channel attack (radiation analysis).

To see how power analysis and a refined version called differential power analysis have been used to break smart cards, check out this paper.
--

Bruce's main site.
Information on Skipjack
Information on impossible-differential cryptanalysis
Information on attacks unknown to the NSA
About the Windows NSAKEY flap
Probable NSA backdoors
Information on the Blowfish algo
Information on the Twofish algo
Speed comparison of known algos
Speed comparison of the AES candidates
Summary of attacks on various algos
Breaking crypto isn't the best way to beat security. Article 1 Article 2
Information on the Solitare algo
Information on the Yarrow algo
Importance of peer-reviewed crypto
Comments on propriatary encryption
Dismissal of cracking contests
You say you can't break it; well, who the hell are you?"
Twofish team's published papers
David Wagner's published papers
So you wanna become a cryptographer?
Information on side-channel attacks
Information on power-analysis attacks
More information on side-channel attacks
Article on Quantum computing
The problems with the public-key infrastructure
The problem with longer keys
l0phtcrack
Biometrics as keys?

Skipjack is not a good choice for several reasons:

1. Skipjack only has an 80 bit key. Even 3DES, at 112 bits, is better than that. Last year, Deep Crack broke a DES key in 56 hours, and the machine cost under $250,000. Assuming the government spent an even billion on a similar machine for Skipjack, they could brute force a key in 26 years. This is unacceptable for the truely paranoid. Rijndael, or any of the other AES candidates, has key sizes of 128, 192, and 256 bits. With a 256 bit key, a brute force search would require more energy than could be obtained by converting all the matter in the solar system.
2. Skipjack has a 64 bit blocksize. As long as you're going with a non-standard algorithm, you might as well use one of the AES candidates which all have 128 bit block sizes.
3. Skipjack doesn't seem to have been sufficiently overengineered to inspire confidence. A version of Skipjack reduced from 32 to 31 rounds can be broken slightly faster than through brute force (look here for details). This isn't a fatal weakness by itself, but it doesn't exactly look good either.
4. If you're woried about the government trying to read your mail, then not using an algorithm they came up with (and thus know more about than anyone else) is just plain common sense.