add support for requiring an extra factor (PIN, passphrase or pattern) with fingerprint unlock to replace split boot / lockscreen password #451
Comments
thestinger
changed the title
thestinger
changed the title
|
Speaking of 2fa, is it possible to implement ubikey+(pass auth/fingerprint) (using the nfc/type-c ubikey)? |
What i meant is if i turn the phone off, i don't want anyone else to be able to start and connect it to a network , wifi, etc. If there was up to me a powered off phone should not even be able to dial emergency without first decrypting it.
This is a great advantage. But i still believe that implementing FBE on top of FDE would be an improvement. Of course you should not drop FBE.
You are absolutely correct. Nobody forces anyone to use the OS.
Right. You have made it clear that this will probably never be implemented, Maybe this should be on reddit instead :) |
It still connected to networks with FDE though, and it's legally required to support that and a bad idea to remove it by default anyway. There's no proper way to have normal settings at that point with FDE because there's no accessible device encrypted user data. FBE makes it possible to support disallowing network access before the initial unlock since it does have settings, FDE is the same environment for everyone even if they want it stripped down more. |
|
I agree if a choice has to be made between one or the other the decision makes itself....FBE I figured you understood all there was about FDE and it still being part of the os and in much more detail than I, it seemed other did not and is why I posted it. I also fully agree FBE is without a doubt needed and best for overall security if we had to choose only one and its done properly. How many people power on their phones and do not login in? Other than update what would be the point? Still have to type in the 64 character passcode for calls txt etc. Otherwise its just a device with a battery draining away. Maybe others are different but I have to think most people either have there phones fully powered down or they have them logged in and only lock protected, in the future, by the fingerprint+pin function. There always seems to be ways found around as opposed to thru encryption. With FBE the surface area becomes huge relative to FDE in a powered on but no credentials passed state. As you have stated FBE implementation in Android still has a ways to go to be fully implemented and is going to have to come in stages unfortunately. Third party apps are also going to have to open up to using and supporting it. Hopefully it will be google mandated eventually. I completely understand having to pick and choose where you (all CH programers) spend time in dev and upkeep with care taken especially in areas you are going to have to update and support with each OS revision. We do not live in an ideal world so fulfilled ideals are rare thus choices have to be made at least in the term. I apologize for stiring the pot on this subject as I would rather have people coding than answering already decided directions. I think the way you guys are planning the initial login and later unlock with fingerprint + passcode up to 5 attempts then a reboot is very good and best choice. i just hope android moves forward quickly in full implementation of FBE security.
Will you be making these kinds of choices available to the user? To me wifi connections emails txt connection would be seen as a security issue with no protection at all anylonger should a phone get lost or stolen. Prior if it was powered down they would have no access to any of this. Now they could have large amounts of data depending how a person configured the phone meaning more opsec. Be nice we could choose thru a menu etc what we wanted or not to be working prior to passcode entry on powerup/reboot. |
|
I definitely don't argue against FBE, but against lack of choice - password + PIN in addition to password + fingerprint. I hope you realize this will lead to people using easy less secure passwords for encryption. I also understand that you will not change your mind. What about informing people how to make an easy Android encryption password (actual key derivation/hashing algorithms used for this purpose by AOSP should be taken into account), but still secure enough? For example how long would it take to guess a 'correcthorsebatterystaple' password set on the oldest still supported Android device (6P) by this machine, how long for the state actor? What about an equally long password but made of non-common/distorted words with a number and a sign in the beginning, fe. '5%corricthoursebaterystaepl'? What about an X char long password generated by one of the standard modern random number generators (fe. openssl, /dev/urandom)? |
|
As fat as i know the cryptographic operations are done in the TEE , which drastically limits the number of guesses ... Removing the memory chips from the phone means trying to crack the AES key (keys in case of FBE) which is still very difficult. However keys HAVE been extracted from the TEE before, but for newer devices they also depend on the password... Using numeric pins or weak passwords is always a bad idea, a strong passphrase should be fine. |
I have no idea what you mean about lack of choice. This issue is filed about implementing support for adding a 2nd factor to fingerprint authentication to make using a strong passphrase as the main authentication method more usable without having fingerprint unlock enabled just by itself. This issue is the wrong place to talk about FDE vs. FBE any more though. It's not what it's about. |
This is wrong. The encryption keys themselves were never stored in the TEE. Nexus devices didn't have proper hardware-bound encryption but you're believing false reporting about the real issue on those. |
|
This thread should be about the initial issue that was filed, not FBE vs. FDE, key derivation or how hardware-bound encryption works. It has never been possible to extract encryption keys though. It's only possible to extract the hardware keys used to help derive encryption keys and they aren't simply stored in the TEE in proper implementations that aren't doing the absolute minimum like Nexus devices were. They aren't supposed to be accessible to software / firmware. Not sure how this is related to a 2nd factor for fingerprint unlock though. |
I think you are not understanding what is changing as what you are stating is actually opposite of what it does. It actually encourages using a very long high entropy password as it only has to be used a power up/reboot. Basically for most people typical usage maybe once a day. The finger print + short pin number is only for unlocking the post login lock screen. It will take your fingerprint + the pin number and if any of it is wrong 5 times the device does a full reboot which then is going to require the full boot up password which can be up to 64 characters. This means for the actual authorized user they are should have no trouble getting a 6 digit pin correct within 5 tries but you are talking lottery number guess chance to get the pin correct within 5 tries if you are having to guess it. Once the adversary get its wrong and it reboots now they are stuck with a impossible to brute force password.and are stuck with only some possible side channel attack which is always possible on any device Dan, Sorry about my part in bringing up anything to do with the FDE. Had no idea it would spur this kind of off topic chain. On to correct topic of adding pin I assumed a 6 digit pin is this what you were planning? |
|
It would be a PIN / password with the user choosing the length just like a normal one. |
|
Thanks awesome so we can have a boot password of up to 64 char and then a separate fingerprint activated password/ pin of that same length. I see why it would have worked with either type of encryption and is actually superior to the old split pwd system. Sounds about as ideal as you can get while not getting overly complex ( yubikey, token etc..) Thanks for all the hard work!! |
|
After tinkering a lot with getting split lockscreen/boot password realized, I finally found a way how this can be achieved even in Oreo (at least on a Nexus, didn't try on a Pixel device). Basically, you have to compile an insecure, root-enabled "userdebug" build first and enable the separate passphrase there, then flash a regular secured build using OTA later. This is quite complicated, however, unless you want to change either passphrase or lockscreen pin you only have to do it once. More details are outlined in the blog post I just published on that: Maybe this might be a temporary solution for some of you until the "fingerprint + PIN" 2FA discussed here gets implemented. |
|
You're posting inaccurate information there. |
|
You mean about this feature not being supported in CopperheadOS officially? Yes I noticed that and will correct this. Any further corrections are always welcome, you can also use the comment function there since it's probably off-topic in here. |
Pixels use the new disk encryption format introduced in Android 7.0 with per-profile encryption keys instead of a global disk encryption key. More recently, logging out of a profile (rather than just locking it) is able to purge the keys and make it become at rest again. The workaround you're using won't work on anything but the legacy Nexus phones. The main reason it wasn't implemented again for our port to Android 7.0 and later versions is because we knew it was an obsolete design and wouldn't work on current generation devices. However, that's not the whole story. It's important to keep as much data as possible at rest rather than simply doing decryption at boot and having the encryption key in memory until reboot. Even with the legacy encryption format, the unlock passphrase is used to protect keystore keys tied to user credentials which can be used by apps to encrypt data and can be sensitive data themselves. One of the reasons for the feature proposed here being substantially better than our previous approach is that it would be a proper secondary unlock mechanism like the existing fingerprint unlock. It can time out and restore the security of the device to being protected by the strong passphrase. It's important to understand that the lockscreen isn't only a UI feature. The screen being locked means that keystore keys requiring user authentication are no longer accessible until the device is unlocked again.
That isn't how hardware support for key derivation works. The TEE firmware is also available without encryption / obfuscation and can be audited. Copperhead has needed to inspect the code of the boot chain and TEE in order to figure out how things are implemented. For example, we needed to figure out how to use Android Verified Boot 2.0 which was undocumented until we submitted documentation to AOSP. It would be nice to have the sources, but the code can be read without them.
It's not correct to claim that only Free Software can be audited / inspected. Nexus and Pixel phones also aren't the only targets supported by CopperheadOS. I also think it's quite odd that you're completely ignoring the entire purpose of CopperheadOS in that section which is the work on privacy and security features. CopperheadOS is not Android without Google services, that's the Android Open Source Project.
Again the with the FUD. |
|
@kuleszdl I also don't understand why your previous post is attacking Android for problems you encountered running a development build of something that isn't Android (LineageOS). It has some very strange reasoning / misunderstanding of what's going on and then jumps to a similar non-sequitur conclusion as this post. I'm not sure what problems you think are going to be solved by moving towards an OS without a security model or basic privacy and security features but best of luck with that. We're looking ahead to a future without insecure mess of the Linux kernel rather than one where everything takes massive steps backwards. It took many years for Android to reach the point it's at now and the desktop Linux stack has a long way to go just to have a comparable security posture to the mess it was years ago. It's tiring hearing the same kind of FUD over and over again. |
|
@thestinger Thank you for the explanations regarding the TEE and the advantages of not having the key in memory while the device is locked. I agree that there is definitely a value in added security of having this feature. I also agree that the article rather compares rather AOSP with Replicant, ignoring the added value CopperheadOS has over AOSP. I will try to fix that in a revision. I have to apologize if some of the arguments I used and the conclusion might have sounded offending to you - this was not intended. I really appreciate all the hard work you guys have put into CopperheadOS. By reading your docs and experimenting with this Android variant I got in touch with a lot new, interesting stuff. I think there are different arguments for and against general aspects of auditability and security of free vs. proprietary software/firmware, but I think discussing this does not really belong in this ticket. Same goes for the Android vs. other systems topic. Back more on topic, I still believe that running Nexus devices (legacy or not) using separated boot/lockscreen passworts is way more secure than just with an even weaker single factor. Since some of the devices also have an (afaik mostly undocumented) download mode, it's hard to judge how easily the keys can be accessed. Therefore, some additional protection here should not hurt. Btw.: The README of this bug tracker states that
Since you previously stated that "Nexus and Pixel phones also aren't the only targets supported by CopperheadOS." I assume the README is outdated? |
It's wrong to claim that lack of access to the sources means it can't be audited though. That doesn't make it a black box. You're making the claim that it's substantially easier to find vulnerabilities in open source software and that not releasing the sources makes it impractical for attackers to find vulnerabilities... it's not at all true.
If the 'other system' is traditional desktop Linux there's not much of an argument to make.
It's nearly always sitting at the lockscreen decrypted so against the kind of attacker you seem to be worried about that encryption has zero value. You also have the wrong impression about how hardware encryption support works. I also don't think legacy devices that are over 2 years old and lack the full CopperheadOS experience are what we should be focused on. The reality is that those devices are almost supported via a legacy maintenance branch and won't be receiving this feature unless it's implemented very soon since they'll only be getting security updates.
The bugtracker README is incredibly out-of-date. I'll just remove most of it. |
|
If your goal is finding a backdoor, not simply low-hanging vulnerabilities, then source access is nearly useless anyway. I think you need to rethink using the security through obscurity argument to claim that closed source software is an impenetrable black box or that somehow reading the code that actually runs on the device is worse than reading sources for thorough audited. Even with reproducible builds, by reading the sources you're completely missing bugs or a backdoor that are only introduced as part of compilation. I wrote about this here: https://twitter.com/CopperheadOS/status/978054189283663872 I think it's important to think about these things in a rational way with clear threat modelling. There are things that you can't audit like the massive complexity of the CPU, GPU, etc. in any device, unlike closed source software which can certainly be audited and inspected especially when they haven't even obfuscated any of it. |
This was not my point - it was about trust in closed-source software, esp. firmware. You are right that closed source software is not more secure; I would even argue that it is often less secure, because less people can audit it (I believe you that skilled specialists can audit the closed source parts anyways, but you hopefully agree that this lowers the number of potential auditors when compared to software where the sources are open). Btw.: As announced, I reworked my blog post, extracting all the "opinionated" parts into another article so it now only deals with the approach for setting the separated password (also making clear that it only applies to Nexus devices). Since Nexus 5 is already EOL for you and the support for the 5X will end pretty soon, I doubt it is worth investing effort into providing more user-friendly support for that. However, if you want to ease applying my "workaround" approach for your users one thing you could think about would be to provide userdebug builds signed by your release key as well - ideally with the same build datetime stamp, so you don't run into the issue that you can't switch between the user/userdebug variants via OTA as the Nexus' bootloader rejects flashing older builds (I assume upstream introduced it due to the "initroot" Nexus 6 vulnerability). |
I don't live in a fantasy world where people are auditing the code that we publish for free. There was an audit of CopperheadOS because a company paid for it and it could have happened without us publishing the sources. CopperheadOS being open source has zero security value in the real world. Pretending otherwise would be dishonest and we don't claim that it's a security feature.
I didn't say it was EOL. I said it's a legacy device that will soon only be supported via a maintenance branch with only bug fixes / security updates.
Official support will probably end in November 2018 but that's not a sure thing. Once official support ends, we'll require funding to continue partial security updates i.e. AOSP-only security updates without new firmware, etc.
No, we're not going to reduce security for our users by publishing userdebug builds signed with the same keys.
That's not the bootloader, it's part of the OS (recovery) and it has always been that way. I'm not sure what connection you're making to any specific Nexus 6 vulnerability. Fastboot mode ( |
|
You can believe in open source as a better development model without trying to portray it as magically granting software better privacy and security. It doesn't work that way. It makes it possible for other people to contribute to a project, but it doesn't mean that they will. I can't come up with a single example / scenario where us choosing to publish sources for the OS has improved privacy or security. It clearly isn't doing that. In fact, the licenses we used made it nearly impossible to earn revenue and continue the project. The privacy and security of our users was harmed by our previous permissive (mostly Apache 2) licensing, and then by the less permissive GPL3 licensing. CopperheadOS would offer better privacy and security today if we had changed the licensing earlier, because it let us start earning some real revenue to fund development and we could be much better off if we had done it sooner. |
Maybe some day someone will audit the publicly available CopperheadOS sources and report their findings to us. That day hasn't happened yet. It has been audited, but not because the sources are published. For the vast majority of open source projects, no one substantially contributes to them and no one audits them. Even for projects like the Linux kernel, the vast majority of the code is only ever looked at by the developers / maintainers other than skin deep changes from tree-wide API changes, etc. The concept of "many eyes" is nothing more than a myth completely divorced from the reality. |
Good point, and you are right - this only works for private builds - didn't fully think about that.
Yes, my mistake. With a locked bootloader you can't flash any partition, you can only do OTA updates. However, refusing OTA downgrades seems new to me - has it really been always like that?
Well, that's sad. But I still think it makes CopperheadOS way more trustworthy than other available options, even if I generally agree to your twitter posts that professionals do not plant obvious backdoors. However, I believe that in cases like the Samsung RIL this would not have happened (this way) if the RIL was open source.
For me, that's rather a question of the business model and not necessarily the license itself. There are several examples (such as nextcloud) where libre licensing works greeat for the business part as well. I guess your business model was too easy to exploit by parties with questionable practices (as it happened) but that's a different story. |
We'll happily start releasing everything under Apache 2 licensing today if we receive funding. It's up to the people that want it to happen to get that funding. The current licensing works fine for us. |
|
Giving everything away for free for no reason and struggling to build a business model around it by doing contract work and trying to sell support makes no sense. It wasn't a viable way to accomplish our goals. It wasn't even a viable way to fund a single full-time developer. Our code is worth money and we'll happily release it under permissive licensing if we're appropriately paid for the amount of research and work that goes into making it. Starting with https://github.com/copperhead/Auditor and https://github.com/copperhead/AttestationServer seems like a good idea. Let us know when you get funding for 2 full time employees to handle development, testing and system administration for those. It needs to have a solid long-term commitment since people will be depending on it for their full-time job. Meanwhile, we'll be pursuing the much more realistic path of using non-commercial licensing for them so we're able to sell commercial licenses and don't need to deal with companies taking our code and using it to compete with us without needing to develop anything themselves. All of their resources can go to marketing, not security research and engineering. |
|
Migrated to the new issue tracker: GrapheneOS/os-issue-tracker#28. |
There should be the option to add a second factor to fingerprint unlock. This would allow using a strong main passphrase paired with a weaker passphrase/PIN usable only via fingerprint unlock when it is applicable (not the first unlock and within a certain time period). Fingerprint unlock is the only convenient way to use a strong encryption passphrase right now, and building upon it would result in a better final result than simply a secondary unlock PIN/passphrase alone.
This is partly a UI feature but it also needs to be wired up to use the extra factor as an additional input for whatever is derived from the fingerprint hash, perhaps just the keystore. An initial implementation without this would be fine, but needs to be marked as incomplete.
The text was updated successfully, but these errors were encountered: