New code strategies to fight side-channel attack Keyless entry systems are ubiquitous, from locking your car to accessing the restricted corridors of government and corporate power. It's therefore troubling to learn Wikipedia reading egg heads have cracked the encryption of a device widely used in a variety of keyless entry systems. There goes the girlfriend's VW, you thought …
"When you do a string compare to check a password, for example, to make it efficient you usually start with the first character and work through in sequence. If you hit a wrong character you throw it out. By measuring the time taken to do the check, a side-channel scan can identify which characters have been accepted. So you can protect the password by not checking it in sequence"
Surely a simpler and cleaner way to do this is to always check all of the characters in the password, failing at the end if any characters were wrong. That way the test always takes the same time (for a given length of password) and no information is available from timing..
What both recent side channel attacks have shown us is that a 'secret' encryption technique rather than a peer reviewed one is a much easier target for to side channel attacks. In both the smartcard and the keyless entry system what was discovered was the weakness in the underlying cryptography.
It is always going to be seriously hard work to prevent people with physical access to your devices, unlimited time, high resolution scopes, JTAG dongles and microscopes from getting the inside scoop on your security through obscurity techniques. Better surely to design using peer reviewed cryptographically strong systems that don't allow you to reverse engineer the master key from any reader?
First thing that is learned when touching security related stuff is - if possible let other do the stuff. :) If not then do it properly. Why I'm writing it? Because sometimes it's better to do it ourself than letting 'specialists' to broke this.
Sometimes 'specialists' think that security is about byte comparing clearword passwords. Have you heard about stuff like that recently in secure code? I did not - away of course of M$ relates shit or open source 'I wanna be sec guru and devise unbreakable XOR 0x55 cipher' stuff. Secure means well planed. Secure means reviewed and re-reviewed and checked again afterwards. Secure means using proper proven methods. And one of those methods is 'close all the doors' (make access difficult if possible) that well protects from such attacks. If 'doors' can not be closed due to physical reasons (such as in cards) then use processing sectioning, hash preprocessing, fixed 'timeshedule' processing. If processor used likes to use power depending on the number of ones in multiplication (just an example) then randomize input to operations. If possible cloak everything with noise and well filter. Impossible? Ask NSA :) Difficult? Then find other job. May be Chinese needs some miners to bury somewhere... Oh! it will hurt mr. CEO and take some money he wanted to spent on a brand new shiny Learjet? Well... Ask that CEO if he wants to be pictured near all that famous Crypto AG guys :)
That wasn't a very impressive sounding "expert" suggestion, though I'm no expert so I may have misunderstood.
Something else I may have misunderstood is why cleartext passwords are ever stored except transiently. Wouldn't it be rather safer to do a one-way encode of the original password (and destroy the clear text), do the same encode when the password is entered for authentication, and compare (the whole of) the encoded passwords.
No stored clear-text passwords, no "side channel" attacks (at least not like the example quoted), no password recovery by swapping memory DIMMs...
No way to generate "The password you forgot is xyzzy" password reminder emails as such either, but they were always a daft idea.
(Not my idea. It's what VMS has been doing since 1978).
Hopefully very few people have a plain password to compare with! What I think they meant is the compare with an encrypted and hidden password. If this uses a string compare then comparing the process time allows one to determine it a byte at a time by going through passwords that encrypt with one byte at a time in order changed - so a 10 byte encrypted password just needs 2560 probes. Of course generating such weird passwords takes some work but even a dictionary of the first 4 characters probably would indicate the general form for a lot of passwords.
A server with access to a cleartext secret can send a "challenge" and demand the client provide a hash of the challenge + secret to login, preventing the transmission of the password over an unencrypted connection. This is used, for example, by the APOP command of pop3. (And if that sounds rudimentary, Outlook doesn't even bother to do this - it just sends it as plaintext.)
But to do that, the server needs access to an unencrypted password. Even if you use encryption on the password file (properly salted, to prevent the use of rainbow tables) then chances are anyone who can get at the password file can get at the master key and decrypt them.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
