Palm vein security bypassed using wax hand models

[watercooled]

If there is any form of communication between host and scanner, I would assume that's a possible route of compromise?

Again, not necessarily, but it does depend on correct implementation as usual, hence why I'm being very careful with my wording. But there are plenty of examples of systems such as smart cards/SIMs which are extremely resistant to attack. The communication protocol should be very simplistic, e.g. all the example I mentioned above would need to send would be e.g. a negative response, or the expected, encrypted random number. The biometric hardware need not be capable of interpreting or sending anything besides this - it's not like it's running a HTTP server or anything.

Failing that (or adding to it), some sort of interception where the host sends out an authentication request, the malware intercepts it and pings back a signal saying, "Uhh, everything's perfectly all right now. We're fine. We're all fine here... now... thank-you... How are you? "?

So in other words, not needing the acual scanner data, just to make the host (or app) think it's gotten the OK from the scanner.

That's exactly why cryptography is used - a single-use random number is sent out by the host to prevent replay attacks (e.g. a fake scanner sending the same exact response which was previously recorded), and the asymmetric encryption prevents the scenario you describe - a fake device would not have the private key required to encrypt the random number, which would be readable with the public key.

There must be a decryption key at the host end or something the malware can use?

It doesn't matter with asymmetric encryption - if malware has access to the public key, we don't care, because that's exactly what we assume anyway. It could decrypt the random number the same as the host, but it wouldn't do it any good. It's only used once (a nonce) so it cannot send it back to the host on another occasion, and even if it could, it still doesn't have that private key to encrypt it.

With asymmetric encryption (AKA public key cryptography), a simplified way of looking at it is as follows: you create two mathematically related but different keys, one is the private key which you must keep secret, and a public key which can be freely distributed. Anything encrypted with the private key can only be decrypted with the public key, and vice-versa. You also cannot decrypt something using the same key used to encrypt. Check out RSA, DSA, and Diffie-Hellman key exchange more more details and the maths involved, if you're not already familiar.

[ETR316]

"doh!"

[peterb]

<—— snip


That's exactly why cryptography is used - a single-use random number is sent out by the host to prevent replay attacks (e.g. a fake scanner sending the same exact response which was previously recorded), and the asymmetric encryption prevents the scenario you describe - a fake device would not have the private key required to encrypt the random number, which would be readable with the public key.


It doesn't matter with asymmetric encryption - if malware has access to the public key, we don't care, because that's exactly what we assume anyway. It could decrypt the random number the same as the host, but it wouldn't do it any good. It's only used once (a nonce) so it cannot send it back to the host on another occasion, and even if it could, it still doesn't have that private key to encrypt it.

With asymmetric encryption (AKA public key cryptography), a simplified way of looking at it is as follows: you create two mathematically related but different keys, one is the private key which you must keep secret, and a public key which can be freely distributed. Anything encrypted with the private key can only be decrypted with the public key, and vice-versa. You also cannot decrypt something using the same key used to encrypt. Check out RSA, DSA, and Diffie-Hellman key exchange more more details and the maths involved, if you're not already familiar.

It’s even better than that though, because asymmetric keys are relatively weak - although good enough for most purposes - but an asymmetric key can be used to send a symmetric one time symmetric session key which is even harder to crack using today’s technology.

[Ttaskmaster]

But there are plenty of examples of systems such as smart cards/SIMs which are extremely resistant to attack.

But not proof against...?

The biometric hardware need not be capable of interpreting or sending anything besides this.

But that could still be a point of intercept, from which to launch an attack/spoof/thing at the host?
Just trying to think of ways to bypass the scanner element, instead of having to cast people's hands in wax and the like...

That's exactly why cryptography is used - a single-use random number is sent out by the host to prevent replay attacks

I assume that spamming the heck out of the host with sequential combinations of keys and 'random' numbers could (in theory) finally trigger the right one? I guess that would be a starting point?
I do know one-time cryptography methods can still be broken, though I haven't read much about them recently.

and the maths involved, if you're not already familiar.

Yeah, ^that's why I tend not to read much about such things. If it's not a calculator function, or a basic Excel formula it's probably beyond me!

[watercooled]

It’s even better than that though, because asymmetric keys are relatively weak - although good enough for most purposes - but an asymmetric key can be used to send a symmetric one time symmetric session key which is even harder to crack using today’s technology.

Aye, like I say I was just using a simplified example. Another reason for using it for exchanging a symmetric key being how computationally expensive asymmetric encryption tends to be - quite a big deal when you're dealing with smart cards etc.

But not proof against...?

That's a term you'll unlikely find in the security world, but when a system has remained secure against malicious attack and security audits for many years you have some assurance some random password-stealing malware isn't going to have much luck, and if some sort of breach does happen, it tends to be a big deal very quickly.

But that could still be a point of intercept, from which to launch an attack/spoof/thing at the host?

Again, not if it's implemented properly, the communication between the devices likely wouldn't be the simplest attack vector in many cases. Cryptographic signing prevents spoofing insofar as the cryptography remains unbroken (and again, assuming it's implemented properly and not using identical keys across every manufactured device for example). For something like forcing a phone to unlock, the host operating system would often be an easier target, but only in the same was as using a pin/pattern to unlock. You still don't end up with biometric data. And you'd e.g. need some sort of exploit and/or root access to the device to modify its behaviour in the first place (one reason blindly rooting phones isn't always the best idea).

I assume that spamming the heck out of the host with sequential combinations of keys and 'random' numbers could (in theory) finally trigger the right one? I guess that would be a starting point?
I do know one-time cryptography methods can still be broken, though I haven't read much about them recently.

Not realistically - assuming no cryptographic breaks (e.g. by using an established ciphersuite) and something like a 256 bit key, you're looking at an unrealistically long time to simply try all combinations. By which time the host should have realised something is up. Oh and give or take, a few billion years might have passed too...

Brute-force isn't a feasible option for bypassing modern cryptography.

Yeah, ^that's why I tend not to read much about such things. If it's not a calculator function, or a basic Excel formula it's probably beyond me!

The theory is simpler than the maths makes it look. Something I find Wikipedia is often guilty of, is providing a near-insurmountable learning curve if you're new to a topic. Sure, the information is there, but it can be incredibly hard to digest if you don't have much background.

[peterb]

Brute-force isn't a feasible option for bypassing modern cryptography.

At the moment, but in the future, who knows?

It’s one reason why the NSA and GCHQ don’t allow public algorithms like RSA to protect sensitive information over the internet or other unprotected networks.

[watercooled]

I was going to add a clause 'with current technology' but didn't want to detract from the weight of the point I was making. If your aim is to bypass cryptography NOW, you're not going to choose brute force with any suitably chosen cipher. It's just miles outside the realms of sanity.

Shor's/Grover's algorithms are theoretical attacks against prime factorisation-reliant problems (i.e. RSA etc) and symmetric encryption, respectively, with Shor's being the most damaging. Grover's algorithm isn't a great threat to symmetric encryption - it theoretically allows bruteforce of a symmetric key in 2^N/2 time, e.g. a 128 bit problem becomes a 64 bit problem, but it's straightforward to simply increase key length to 256 bits, which is commonplace now, and you still have a 128 bit complexity problem to solve. And for anyone unfamiliar with such statements, it's hard to stress just how incredibly hard that is. It's not an option. Read up on bruteforcing 256 bit keys and the Landauer limit for a laugh - I forget what bit length is required but assuming the Landauer limit i.e. the lower bound for irreversible computation (which you won't actually achieve because besides just counting through keys you need to spend some cycles and energy on doing comparisons etc), you reach a point where you require more energy than exists in a star, or beyond.
https://fspreen.github.io/2016/10/08...er-future.html

256 bit doesn't sound very much, and indeed it isn't in length, just 32 bytes, but that means 2^256 or 115792089237316195423570985008687907853269984665640564039457584007913129639936 possible combinations to try. On average you'll get by with half of that number, but it doesn't help much.

Shor's algorithm relating to many forms of asymmetric encryption is far more damaging, and would make many standard forms of such encryption practically useless where an adversary has access to a sufficiently large and powerful quantum computer. But that last part, while often treated as a footnote, is a major sticking point. We don't have, nor are anywhere close to having, a sufficiently large quantum computer to run the algorithm on a real key. It is not a requirement to simply have 'a quantum computer' where e.g. it runs a bit slower - you need one large enough or you get nothing. Having said that, if you're in a position where you feel an adversary may possess such a computer in 'just another 10 years' as Schneier puts it, and the information you're transmitting needs to be kept secure beyond that timeframe, then it's worth considering other options. I imagine that's partly why NSA/GCHQ/etc don't rely on them for higher security stuff - it's unlikely someone will have a capable system any time soon, and one being created is not guaranteed, but it is obviously a cause for concern for these organisations.

Yes, it's something the security community need to and are considering right now, but as far as the theory behind my explanation goes, it's not really all that relevant. Check out 'post quantum cryptography'. http://pqcrypto.org/

Bruse Schneier has spoken about these topic many times, e.g. https://www.schneier.com/blog/archiv...computi_2.html
And also an excerpt from his book Applied Cryptography can be found here (the article itself isn't really relevant, it's just the only place I could find it - scroll down to the quote): http://www.bitcoinnotbombs.com/bitco...ntum-computer/

Oh and before anyone suggests other methods of attacking symmetric keys or implementations, at that point it's no longer a bruteforce search, and my point was simply to express how incredibly infeasible such an attack is.