5 ms·

You can get the slides here - https://media.defcon.org/DEF%20CON%2024/DEF%20CON%2024%20presentations/DEFCON-24-Plore-Side-Channel-Attacks-On-High-Security-Elect

You can get the slides here - https://media.defcon.org/DEF%20CON%2024/DEF%20CON%2024%20presentations/DEFCON-24-Plore-Side-Channel-Attacks-On-High-Security-Electronic-Safe-Locks.pdf https://media.defcon.org/DEF%20CON%2024/DEF%20CON%2024%20pre... It really is a clever attack! I'm really surprised at the way he mentions the microcontroller tests if the key is correct or not, by simply looping through and breaking on an incorrect number.

pwg 10y ago
Not surprising at all. It is a standard pattern when programming for performance (which is what 99.9% of programmers are going for 99.9% of the time). Once you are sure the answer's wrong, don't bother testing any more of it. And for performance, this is correct, because you don't execute useless unneeded instructions. The problem, of course, is that in the security realm, coding to break the loop as soon as the answer is known wrong is what provides these types of side channel attacks. But since 99.9% of programmers also do not write code for these environments when tasked to do so they just do what they are used to doing everywhere else (break early, when you know you are done with the checks) without realizing they are leaving an unlocked backdoor as a result.
- yock 10y ago
  This was somewhat famously broken in Java until late 2009: https://codahale.com/a-lesson-in-timing-attacks/ https://codahale.com/a-lesson-in-timing-attacks/ tl;dr, the method for doing "secure" string comparison was vulnerable to timing attacks for much of Java's history.
- jamiesonbecker 10y ago
  Exactly. If you're doing something like: if hashing_function(unknown_pass) == hashed_pass: you're doing it wrong... Instead, use the compare function built into your crypto library, which should hopefully be hardened against timing attacks. In most languages, == and === are not safe against timing attacks.
  - cmdrfred 10y ago
    I never knew that damn. What if I added a random delay of a few ms after I compare them?
    - _asummers 10y ago
      Nope! If you run the same input enough times, you can get enough data to be able to subtract the random noise out; the larger random number range, the more times you have to run it. The way to properly combat timing attacks is to write constant time code. Daniel Bernstein has made his career talking about and implementing this class of crypto.
      - cmdrfred 10y ago
        Humor me, I think figured it out, run an identical "testPass()" function first and time it ('password' == 'password' if you will), then simply wait at least that length of time before acting on the result. As a bonus add a random delay after that so adversaries might waste time on isolating the randomness as you describe.
        _asummers 10y ago
        If you really want to add some sort of randomness, make it based on the user input. That way your randomness depends on what you send and won't be able to be subtracted out. Or use constant time things (which is hard for the record!) and not have to deal with it.
  - SilasX 10y ago
    Why would that leak key material? Knowing that you matched a few characters of the hash (based on earlier exit and quicker response time) doesn't tell you that some of the password characters match -- a partially-matching password shouldn't have an relationship to a fully-matching one, right?
    - jamiesonbecker 10y ago

pwg 10y ago

Not surprising at all. It is a standard pattern when programming for performance (which is what 99.9% of programmers are going for 99.9% of the time). Once you are sure the answer's wrong, don't bother testing any more of it. And for performance, this is correct, because you don't execute useless unneeded instructions. The problem, of course, is that in the security realm, coding to break the loop as soon as the answer is known wrong is what provides these types of side channel attacks. But since 99.9% of programmers also do not write code for these environments when tasked to do so they just do what they are used to doing everywhere else (break early, when you know you are done with the checks) without realizing they are leaving an unlocked backdoor as a result.

yock 10y ago
This was somewhat famously broken in Java until late 2009: https://codahale.com/a-lesson-in-timing-attacks/ https://codahale.com/a-lesson-in-timing-attacks/ tl;dr, the method for doing "secure" string comparison was vulnerable to timing attacks for much of Java's history.
jamiesonbecker 10y ago
Exactly. If you're doing something like: if hashing_function(unknown_pass) == hashed_pass: you're doing it wrong... Instead, use the compare function built into your crypto library, which should hopefully be hardened against timing attacks. In most languages, == and === are not safe against timing attacks.
- cmdrfred 10y ago
  I never knew that damn. What if I added a random delay of a few ms after I compare them?
  - _asummers 10y ago
    Nope! If you run the same input enough times, you can get enough data to be able to subtract the random noise out; the larger random number range, the more times you have to run it. The way to properly combat timing attacks is to write constant time code. Daniel Bernstein has made his career talking about and implementing this class of crypto.
    - cmdrfred 10y ago
      Humor me, I think figured it out, run an identical "testPass()" function first and time it ('password' == 'password' if you will), then simply wait at least that length of time before acting on the result. As a bonus add a random delay after that so adversaries might waste time on isolating the randomness as you describe.
      - _asummers 10y ago
        If you really want to add some sort of randomness, make it based on the user input. That way your randomness depends on what you send and won't be able to be subtracted out. Or use constant time things (which is hard for the record!) and not have to deal with it.
- SilasX 10y ago
  Why would that leak key material? Knowing that you matched a few characters of the hash (based on earlier exit and quicker response time) doesn't tell you that some of the password characters match -- a partially-matching password shouldn't have an relationship to a fully-matching one, right?
  - jamiesonbecker 10y ago