Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Linux port? #1

Open
piranna opened this issue Oct 31, 2016 · 13 comments
Open

Linux port? #1

piranna opened this issue Oct 31, 2016 · 13 comments

Comments

@piranna
Copy link

piranna commented Oct 31, 2016

Neat hack! :-D I know this project is focused on OSX, but would it be possible to port the same idea de Linux sudo command? :-) I don't hace a TouchID enabled machine, but I think it's something could be REALLY useful... :-D

@kailan
Copy link

kailan commented Oct 31, 2016

Unless you have Linux running on a new MacBook, it would be useless.

@piranna
Copy link
Author

piranna commented Oct 31, 2016

There are other devices with a thumb sensor...

@kailan
Copy link

kailan commented Oct 31, 2016

Yeah, but there are existing solutions for sudo with fingerprint readers. This is specifically for TouchID.

@piranna
Copy link
Author

piranna commented Oct 31, 2016

Oh, didn't know of them, thanks :-)

@i336
Copy link

i336 commented Oct 31, 2016

I did a bunch of research about fingerprint readers recently, so I'll just leave this here as this project looks (understandably) popular right now. For anyone who likes security, I made you a wall of text!

  • Touch ID authentication is handled by the Secure Enclave (= a very large pile of crypto) running on a dedicated processor, the T1. At the end of the day, the macOS authentication framework just gives a go/no-go binary response ("yes, okay" or "no, failed"). I'm not sure if there's some authentication happening between macOS and the T1 to make this happen; in any case the controller probably stores the fingerprint data in secure flash storage or something (yay).

    Now, you might be able to get Linux to play ball with the T1. However, it's hard to defend the argument that the sniffing around and level of technical investigation necessary to get Linux support working might compromise security (think 0days). Considering the saga with what happened when the iPhone's Touch ID sensors got disconnected for repair... if the system is ever figured out, it's likely it won't remain figured out for long (eg, next hardware revision = totally different protocols, etc).

  • fprint generally supports almost all the fingerprint readers that are out there, even though it's a couple years old now. It works, too; I just tried it on an old laptop I have here a few days ago, it immediately found the fingerprint reader, and enrollment (in the test GTK app) worked, etc etc. Fun! :)

    CAVEAT EMPTOR.

    Touch ID on the Macbook, iPhone (and hopefully Watch, in future?) are handled by dedicated secure processors, very probably secure memory, and lots of isolation. This makes the go/no-go that comes back very secure. But at the end of the day, the macOS side needs to go if (response_ok) { ... } else { ...}; let's see how long it takes for someone to find the critical cmp and make macOS think a bad read was actually a good one.

    Put another way, a perfect security system would take the digitized, normalized output of the fingerprint reader and use that value directly as eg a dm-crypt passphrase or similar. That means your fingerprint is literally the password, which is the intuitive interpretation... and it would be really awesome if that was actually how it worked, but perhaps unsurprisingly, fingerprint readers seem to generally just do "yup, I know that fingerprint" or "who r u???", and it's the (fragile!) software side that needs to divert off eg unlocking the system or completing the transaction if the fingerprint was bad.

    As I said before, I'm not sure if macOS has some authentication chatter in the verification process besides the basic proprietary protocol being used. Basic Touch ID stuff probably just gives a binary "ok"/"fail" as described above, but the Apple Pay part is likely likely more sophisticated, maybe even with keysigned messages that go straight from Apple's servers into the T1 for verification (via PKI keys burned into secure memory). That would be the right way to do it, and it sounds like they may have achieved that.

    On Linux, the critical cmp that acts upon the fail/ok response is running typically in a root-level process (eg pam_fprintd.so), not squirrelled away in something like SMI (ideal, but impossible) or even the kernel. ¯_(ツ)_/¯

TL;DR: just use your fingerprint to unlock your computer, it's basically just a button at the end of the day because of how fingerprint readers are implemented. Great for making it utterly impractical for someone to keylog your laptop while your back is turned for 5 minutes, but woefully insufficient insecurity for eg unlocking an encrypted disk.

PS. Some fingerprint readers are capable of imaging, which (perhaps obviously) gives you a copy of the fingerprint image/scan (incidentally, the old fingerprint reader I played with only has imaging support via the Windows driver, the data stream to the Windows driver is horribly obfuscated sadly), but that would need to then be normalized via some recognition algorithm. Basically fingerprint readers as implemented on PCs are, like TPM enclaves, paper tigers.

@getaaron
Copy link

@i336 A few notes:

• Touch ID stores a one-way hash of your fingerprint, not your fingerprint itself
• The issue you mention with booleans is only true if you use the LAContext API. You can instead encrypt a password (or other information) with the Touch ID hash using SecAccessControlCreateWithFlags. You can pass touchIDAny or touchIDCurrentSet depending on which access level you want.

@i336
Copy link

i336 commented Nov 1, 2016

Oh, interesting!

  • Touch ID stores a one-way hash of your fingerprint, not your fingerprint itself

A hash makes perfect sense: the raw fingerprint data is going to be different (angle, pressure, ambient light, ...) every time, so it needs to be normalized and sanitized somewhat. My fingerprint reader handles this in the most dismal way possible: successful enrollment (swiping 3-4 times) causes the controller to emit a 200 byte binary blob that you're supposed to receive then save to disk, then feed back to the controller at verification time. After thinking about it for a bit I haven't been able to come up with an interesting sounding attack for this mechanism, but I far prefer the fact that Touch ID (presumably?) stores the hash in secure memory. (It does, right?)

  • The issue you mention with booleans is only true if you use the LAContext API. You can instead encrypt a password (or other information) with the Touch ID hash using SecAccessControlCreateWithFlags. You can pass touchIDAny or touchIDCurrentSet depending on which access level you want.

Oh, that's nice. How does that work? Streaming the data through the secure processor, which encrypts/decrypts it without revealing the key?

@WhyNotHugo
Copy link

Unless you have Linux running on a new MacBook, it would be useless.

That's what I would assume the request is for.

So is there any interest in this, or is it too out-of-scope?

@serverwentdown
Copy link

I'd say this is out of scope.

@WhyNotHugo
Copy link

Yeah, I did some research since my last comment here, and the hardware for the TouchBar/TouchID isn't even supported on linux yet, so there's no chance of this happening for now (I'm keeping an eye for future's sake anyway, I still have a 2015 model).

@akatrevorjay
Copy link

akatrevorjay commented Mar 9, 2018

Just use PAM. It's already supported and been supported for years.
(You can get fprint detection and such with fprintd, which may need a driver for touchid. I swear I read that someone wrote an initial one though.)

@akatrevorjay
Copy link

akatrevorjay commented Mar 9, 2018

I'm actually confused a little that the osx version of sudo doesn't use pam anymore? They may have continued moving away from it for all auth purposes for all I know at this point (been a few years since I've used it heavily).
If it requires a sudo fork due to that, then man, that's a really gross thing to move towards [Apple]

@unknowntounknwon
Copy link

what about this,
fprintd supported only swipe so what if we do instead of swipe we can use touch so it work like macos touch id.
but the problem is fprintd support only swipe.
although windows support
touch fingerprint support.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

8 participants