Read more.Quote:
Hackers could bypass both Fujitsu and Hitachi palm scanners (95 per cent of the market).
Printable View
Read more.Quote:
Hackers could bypass both Fujitsu and Hitachi palm scanners (95 per cent of the market).
I have some sympathy with Fujitsu, etc, on this, and bear in mind I'm somewhere closer to the cynic/paranoid end of the spectrum re: asoects of internet security.
To achieve this "hack" the researchers appear to need to take photos, using a converted infra-red camera, of a user's palm.
Maybe I'm too cynical, but I think most users not only the paranoid, might be just a bit suspicious of someone saying "stick your hand in here, palm down and open, while we take a picture" and, ummm .... decline. Firmly.
If their hack had a way of bypassing neefing access to the user's palm, or some innocuous way of getting that, they'd hsve a point.
But so far, all they seem to have demonstrated is a basic weakness, which is if you can get to the original biometric spurce, whatever that is (fingerprint palm, iris, whatever) AND copy it, then that biometric security is blown open.
But they haven't.
Yet.
Probably wouldn't take much - Fake readers, piggybacking data sources, perhaps the usual virusy-trojan things you are tricked into clicking that then install data harvesters in your computer and pass on your scans....Quote:
Originally Posted by Saracen999
Once one of these systems is compromised, wouldn't you have biometric data of basically everyone using that system anyway?
With a password you can at least try to use a different password for every place you visit. But the palm of your hand (or iris, or fingerprint) is much more difficult to change.
Not necessarily - properly implemented, biometric systems will only store something akin to a hash of the data, from which you cannot recreate the original input. That doesn't stop someone simply lifting fingerprints or iris photographs though. Assuming these traits uniquely identify an individual for security purposes can be a fairly dangerous assumption to make for that reason. And as has been show, some rubbish implementations of e.g. fingerprint scanners can be fooled with something as simple as one printed on a piece of paper.Quote:
Originally Posted by Waswat
Again, a properly-made biometric device won't expose raw biometric data to the host computer.Quote:
Originally Posted by Ttaskmaster
So, what you're saying is that the cake is real but we only expose it as a lie to the host so they can't re-create its deliciousness.Quote:
Originally Posted by watercooled
Gotcha.
Ah, so as long as the fake reader attached to a device by the thief looking to steal your info is properly made, it won't reveal your BioData. Good to know...Quote:
Originally Posted by watercooled
To be fair the article claims a picture from 5m (15ft) is sufficient, that seems like quiet a long distance, although not knowing much about photography maybe it's not, IDK.Quote:
Originally Posted by Saracen999
I know little about the detail theory of photography but dabble in it and even my meagre kit can take a pretty decent tele-macro image from 5m. It's all about having the right lens and enough light for a reasonably quick shutter speed to keep things sharp. If they need true macro quality it's more tricky, but not impossible SFAIK, but I imagine those palm scanners aren't mapping every wrinkle or line like a finger print, but the palm lines - which are much more visible.Quote:
Originally Posted by Corky34
5m is not that far. 4.8-5m is the length of a standard carparking space. Not far at all.
Yea sorry, when i said that seems like quiet a long distance it was in the context of stick your hand in here, palm down and open, while we take a picture, basically at 5m it's something that could, theoretically, be done without the target noticing.
I skipped over the bit about 'fake readers' - that's an issue of course, if you're in an environment where you cannot trust the hardware for example. The rest should be covered though, e.g. malware on the host system should not be able to access such data. Furthermore, biometric data should not be stored in its raw form anyway. Again, in a properly-implemented system, I'm making no claims about which systems meet that criteria! And nor do I have much faith that some company won't think they know better than everyone else and create their own terrible implementation.Quote:
Originally Posted by Ttaskmaster
so.. the guy at the office party trying to get girls to scan their bums on the photocopier was inventing the foolproof security system he claimed they had to do it for..?
Many biometric hacks are done with the cooperation of the subject. For example in some parts of the world factory time clocks will check each worker's fingerprint as the clock in at the start of the day, so that people can't clock in their mates who are not actually there.Quote:
Originally Posted by Saracen999
This has given rise to a cottage industry that makes fake fingers that will fool the time clock. These are of course made with the full knowledge of the owner of the finger being copped, as they will be main recipient of wages for time not worked (less the kickback to their accomplice who clocks them in).
In other words not all biometric hacks need to be stealthy to break security.
More that you're in one where it has been so widely adopted that you don't have a choice...Quote:
Originally Posted by watercooled
Except that, with the advent and widespread use of such tech, all the malware has to do is spoof something or otherwise trick the user into enabling such access (in the same manner that many people have their apps store passwords and auto-login), and you're away.Quote:
Originally Posted by watercooled
Humans are always the weakest link.
I'm predicting an episode of The Real Hustle where Jess plays a waitress and takes your glass/cutlery away, while Paul pilfers your MacBook from your bag and passes it to Alex, who has already lifted your prints off the tableware, forged every finger that touched it and is ready to simply swipe-access your personal data...Quote:
Originally Posted by watercooled
Just the one company.....?Quote:
Originally Posted by watercooled
Agreed, but I was speaking more about the odd malicious device being used like card skimmers for example - where people might use them not realising they're malicious. If you're suspicious of hardware you own, it's obviously a concern but that's entering the realm of targeted attacks. I'm also speaking about malicious hardware rather than plain badly made, but the same can obviously apply.Quote:
Originally Posted by Ttaskmaster
Not necessarily. Again I'm referring to properly designed systems rather than something like a dumb scanner relying on the host for authentication, but in said 'proper' system, they will be designed so malware cannot act as a middleman, and such access is not something the user could grant either, it's just not the way they work. Check out stuff like secure enclave. You would have to target and breach the security of the physically separate security hardware which would be no small feat - malware on the host would be useless otherwise (as far as recovering biometric data goes anyway). Regardless of secure data stores, they won't actually store nor be capable of passing raw scan data anyway - even those secure stores would only store something like a hash of the data, and much like a SIM card, authenticate users without having to reveal any confidential data.Quote:
Originally Posted by Ttaskmaster
It can works something like this (massively oversimplified before anyone steps in to correct me, and it's just one example of a variety of approaches):
Host asks scanner to authenticate user over a secure channel.
Scanner takes scan and compares scan data and compares against internal database (check how fingerprint scanners work for more information - they don't actually store a photo of the fingerprint).
After confirming scan, the scanner e.g. encrypts a random number, provided by the host over the secure channel, with scanner's private key.
The host receives this encrypted data and, by decrypting it with the scanner's public key, cryptographically proves it was created by the scanner, confirming it as authentic.
As you can see, the host has nothing to do with the actual biometric data and is simply relying on the biometric scanner to give it the thumbs up or thumbs down, and relies on asymmetric encryption techniques to prove authenticity of said messages. None of the data available to the host system would be of any use to malware.
So was I, in that they'd be less odd and more common as the technology sees wider use. Case in point, the fake cash dispensers that get you to put your card in and enter your PIN before simply pretending they're out of cash.Quote:
Originally Posted by watercooled
If there is any form of communication between host and scanner, I would assume that's a possible route of compromise?Quote:
Originally Posted by watercooled
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.
There must be a decryption key at the host end or something the malware can use?Quote:
Originally Posted by watercooled
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.Quote:
Originally Posted by Ttaskmaster
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.Quote:
Originally Posted by Ttaskmaster
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.Quote:
Originally Posted by Ttaskmaster
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.
"doh!"
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.Quote:
Originally Posted by watercooled
But not proof against...?Quote:
Originally Posted by watercooled
But that could still be a point of intercept, from which to launch an attack/spoof/thing at the host?Quote:
Originally Posted by watercooled
Just trying to think of ways to bypass the scanner element, instead of having to cast people's hands in wax and the like...
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?Quote:
Originally Posted by watercooled
I do know one-time cryptography methods can still be broken, though I haven't read much about them recently.
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! :DQuote:
Originally Posted by watercooled
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.Quote:
Originally Posted by peterb
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.Quote:
Originally Posted by Ttaskmaster
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).Quote:
Originally Posted by Ttaskmaster
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...Quote:
Originally Posted by Ttaskmaster
Brute-force isn't a feasible option for bypassing modern cryptography.
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.Quote:
Originally Posted by Ttaskmaster
At the moment, but in the future, who knows?Quote:
Originally Posted by watercooled
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.
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.