The problem with this approach
on
Inkblot Passwords
·
· Score: 5, Insightful
One of my college professors actually outlined a similar scheme several years ago. But (as he admitted) it had a fatal flaw: the keyspace was too small. In other words, it is not hard to assemble a list of under 50 possible passwords or two-letter combinations that describe a given inkblot.
The other flaw (which is less serious) is that this strategy is only effective when the user has to remember a small, finite number of inkblots. If a user is forced to memorize a few hundred inkblots to cover the dozens of passwords he needs on a daily basis, this mnenomic technique loses its value.
I have been following DTV news since "black Sunday" back in 2001, and all I have to say at this point is that pirates should be afraid, very afraid. DirecTV has seen piracy numbers skyrocket in the past few years as hundreds of (mostly American) dealers have sprouted up to sell pirate cards. Slowly and meticulously, they have begun to fight back and the tide is quickly turning. For instance:
DirecTV has shut down dealers. From the Great White North to Florida, DTV has sued and prosecuted anybody involved in selling programmed cards or smartcard equipment. (Often this equipment has many legitimate uses, but that is not a concern for them, is it now?) Dealers, wary of spending 20-30 years in prison for a victimless crime, turn over their customer lists as part of their settlement. Which brings me to my next point:
DirecTV has sued end-users. You can see them brag about it here. They presume guilt and ask the end-users of perfectly legitimate smartcard equipment to pony up $4000 or risk being sued in Federal court. The vast majority of these users, lacking backbone, settle. This makes a lot of money for DTV and allows them to expend even greater amounts of resources suing more innocent end users.
DirecTV has shut down informational sites. Starting with blatantly money-grubbing sites like decodernews.com (which sold subscriptions for hacking software) and progressing to the milder sites like hitecsat.com, they have stemmed the flow of information on conditional access technology. Their goal is to squelch all public discussion of smartcard technology and to keep the populace ignorant of how these systems work.
DirecTV has introduced two unhackable access cards. They have introduced a P4 card and a "P4.5" card, neither of which are vulnerable to any of the security holes that were exploited in their P3, P2, and P1 cards. The P3 was an exceptionally strong card, protected with encrypted ROM, encrypted EEPROM, encrypted RAM, an ASIC designed by Ron Rivest (of the RSA fame) with 256-bit stream ciphers, and strong physical security. The P4 is proving to be even more invincible than any other access card in existence; disassemblies posted at dssunderground.com point to the use of 3072-bit Diffie-Hellman private keys and dozens of booby traps hidden in the code. It may be virtually impossible to develop a commercially viable crack for the P4 and P4.5. Since the P3s are scheduled to be swapped out by the end of August, a lot of pirate TVs will be going dark very soon.
DirecTV is introducing new receivers. These new receivers (which are denoted by an "RID" number on the box) are specifically designed to detect hack attempts and to notify DTV of any anomalies. For instance, hackers attempt to "emulate" an access card with a PC, by setting the card slot serial baud rate to 19200bps instead of the usual 57600bps, to compensate for latencies introduced by the software. These new receivers detect this change and "flag" it as abnormal; DTV can detect this condition and send a technician to "check" on the setup, just as cable companies do when they see an unfiltered pirate box on the line.
So, the moral of the story is, don't bother getting into this mess (I'm glad I never did), because the game will be over soon.
The paper was admittedly somewhat difficult reading for those of us who are
not frequently subjected to academic research texts. However, I would like
to take some time to shed some light on the topic for those of you who do
not have an Master's degree from Harvard as I do.:)
These timing attacks are very different from those executed against an
embedded device, such as a smart chip, in that the attack against the smart
chip aims to disrupt the device and cause it to skip one or more
instructions in order to breach the security. These attacks instead use
timing attacks as an oracle which allows the malicious hacker to
make thousands of guesses against the insecure server, knowing that the
timing of the response will eventually give away the key. For instance,
by sending a specially crafted packet to one of these vulnerable SSL
servers, one will be able to deduce from the timing whether a given
bit in the private key is a 0 or a 1, simply by looking at how much time
it takes to respond (on the average, for that particular crafted
input). You can see how this could be a bad thing.
Although this could be a very nasty threat today for machines within a
small, predictable network distance from the attacker, there is hope. In
the 2.5 kernel, developers have begun adding features that randomize round
trip latency for packet reponses. This means that these systems will not
serve as good oracles for an active attacker because the timings generated
by the randomization feature will not approximate an even (normal)
distribution. This means that even by averaging them out, it will not be
possible to determine from the timing of a cryptographic response whether
(say) the bit is a zero or a one.
This vulnerablility has actually been discussed as a possiblility for the
past few years (mostly within the CERT "members only" club) but it was not
until recently that a practical exploit was published. So if your keys
were compromised before this went public, perhaps one of the blackhats
figured the trick out first.:(
Slashdot Mirror
The other flaw (which is less serious) is that this strategy is only effective when the user has to remember a small, finite number of inkblots. If a user is forced to memorize a few hundred inkblots to cover the dozens of passwords he needs on a daily basis, this mnenomic technique loses its value.
So, the moral of the story is, don't bother getting into this mess (I'm glad I never did), because the game will be over soon.
These timing attacks are very different from those executed against an embedded device, such as a smart chip, in that the attack against the smart chip aims to disrupt the device and cause it to skip one or more instructions in order to breach the security. These attacks instead use timing attacks as an oracle which allows the malicious hacker to make thousands of guesses against the insecure server, knowing that the timing of the response will eventually give away the key. For instance, by sending a specially crafted packet to one of these vulnerable SSL servers, one will be able to deduce from the timing whether a given bit in the private key is a 0 or a 1, simply by looking at how much time it takes to respond (on the average, for that particular crafted input). You can see how this could be a bad thing.
Although this could be a very nasty threat today for machines within a small, predictable network distance from the attacker, there is hope. In the 2.5 kernel, developers have begun adding features that randomize round trip latency for packet reponses. This means that these systems will not serve as good oracles for an active attacker because the timings generated by the randomization feature will not approximate an even (normal) distribution. This means that even by averaging them out, it will not be possible to determine from the timing of a cryptographic response whether (say) the bit is a zero or a one.
This vulnerablility has actually been discussed as a possiblility for the past few years (mostly within the CERT "members only" club) but it was not until recently that a practical exploit was published. So if your keys were compromised before this went public, perhaps one of the blackhats figured the trick out first. :(