add support for requiring an extra factor (PIN, passphrase or pattern) with fingerprint unlock to replace split boot / lockscreen password

[thestinger]

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.

[Kokokokoka]

Speaking of 2fa, is it possible to implement ubikey+(pass auth/fingerprint) (using the nfc/type-c ubikey)?

[thestinger]

The main unlock mechanism is intended to be a strong passphrase and it won't be possible to enhance that with a 2nd factor. The only thing that's on the table is adding additional factors to a secondary unlock mechanism. The reliability of the primary unlock mechanism is crucial and can't ever be impacted by dropping features. Features that cannot be removed won't be implemented.

There won't be a secondary unlock mechanism without a fingerprint because it's how secondary unlock is initiated rather than pressing the power button (or double tapping on the screen) and swiping to use the main unlock mechanism.

It would be possible to have the options of fingerprint + PIN + NFC key or fingerprint + NFC key in addition to fingerprint alone or fingerprint + PIN. However, an NFC key would be a very niche feature and is not going to be implemented before this feature planned since August 2016. Unlike this feature which has always been a high priority, just without resources available to implement it, an NFC key option would be a very low priority and would be unlikely to ever happen.

It's quite possible that we wouldn't accept a patch for an NFC key option because we wouldn't be interested in spending years maintaining it and porting it to new versions of Android for the tiny group of people that would use it. If it's not something that >30% of people can be expected to use, it's not a good fit for CopperheadOS unless funding is being provided for development and maintenance of the feature with it being dropped as soon as the funding ends.

[ghost]

There won't be a secondary unlock mechanism without a fingerprint because it's how secondary unlock is initiated rather than pressing the power button (or double tapping on the screen) and swiping to use the main unlock mechanism.

Is this dictated by newest Android version? Why not implement it just as you implemented it before (main password for booting, secondary password (PIN) initiated with power button)?

[xbtc-im]

I'm guessing this cannot be done because the new devices switched from full disk encryption to file based encryption. Full disk encryption was similar to Linux dm-crypt / luks, one key unlocked by the "long" password was used to encrypt/decrypt the entire /data partition.

File based encryption uses multiple keys to decrypt different files, some are protected by the password/pin , some stored in the silicon. Parts of the filesystem are available before the user enters the password to unlock the device (direct boot).

Those systems are totally different so the old implementation is difficult. As thestinger said in a different post, it might be possible to implement FBE on top of FDE but i guess it's a lot of work, and you will lose the direct boot feature (automatic updates, alarms, etc)

[thestinger]

The encryption keys for credential encrypted storage are per-profile. There will end up being a third class of data that's also credential encrypted but becomes at rest when the device is locked without needing a reboot or profile switch. There's no boot password and it doesn't fit into the design.

The legacy implementation on the Nexus 5X and 6P isn't what we're working on improving.

There's no advantage to the old mechanism we used compared to having the option of fingerprint + PIN because that's not less convenient than a PIN alone while being strictly more secure. It requires non-trivial development work instead of simply decoupling two passwords and it hasn't yet been implemented because our hands are quite full simply maintaining the OS and porting features to new versions. There are still a bunch of Oreo features to port despite it being released all the way back in August.

[TimFW]

So to be clear what is on the table is the following:

Standard Power cycle/power on password up to 64char

secondary unlock feature that combines fingerprint scan which activates pin number. If max pin number attempts is reached (IIRC 5) it triggers a reboot which then requires the full password to be entered.

Is the above correct?

To me if properly implemented this is the ideal to have. It creates a way to keep high level of security once booted yet allow easy user access thus increasing assurances of us of more secure password.

I love my androids and will never convert but security was a jonny come way late priority for android. But then would not have Copperhead then which I am very happy to have.

---

I do want to point out that according to AOSP official doc the old legacy FDE is something that is still part of current version. It was never removed.

https://source.android.com/security/encryption "Android 5.0 and above supports full-disk encryption"

Also FDE was using linux dmcrypt but it was Cryptfs IIRC cmds are found in the cryptfs.c file.

The issue is likely you can not use both encryption types together Android . I simply do not play enough with Android to know but I am sure the guys at Copperhead can or someone else on here can explain in basics or detail why and how etc.. I do not mind extra steps so for me I would be happy to have both if it was properly implemented. I have no issue running some adb commands to activate and setup FDE password. But my guess is as its been tied to the lock screen etc that its one or the other not both but I do not know for sure.

[xbtc-im]

As far as i understand, FBE is implemented on top of ext4. In theory at least you could implement FBE on top of FDE (use the dmX device instead of sdXY). You would of course lose direct boot features. But i guess it's a lot of work and the devs simply don't have the time to address this. Maybe if the people requesting certain features would pay for their development, would that be acceptable ?

On a side note , i don't really understand how this works: "becomes at rest when the device is locked"

If the relevant data is encrypted when you lock the device, what happens when you receive an e-mail / message / call etc ? How does an app access it's relevant data folder sine they are encrypted ?

[thestinger]

I do want to point out that according to AOSP official doc the old legacy FDE is something that is still part of current version. It was never removed.

I'm quite aware that it was never removed. It's still used on the Nexus 5X and 6P. Disk encryption isn't able to achieve our security goals with FDE though.

[thestinger]

If the relevant data is encrypted when you lock the device, what happens when you receive an e-mail / message / call etc ? How does an app access it's relevant data folder sine they are encrypted ?

There are already data classes. Apps get credential encrypted storage by default and can explicitly opt-in to a database / file / preference being device encrypted instead. Data at rest while locked will work the same way.

[thestinger]

But i guess it's a lot of work and the devs simply don't have the time to address this.

It's not something we want in the first place. We want FBE with it used to protect data when locked and to enable features like our current automatic updates before the first login since booting which combined with the opt-in idle reboot option can properly maintain a device without active use.

[thestinger]

There are drawbacks to the current FBE implementation compared to FDE but they can be addressed, and it already has significant advantages. This issue is not about FBE vs. FDE though. The proposed feature will work for both and will work better than the FDE-specific change we used to have. It wouldn't even matter if we still had only FDE, this is the feature we want, not what we used to have. I don't really see the point of rehashing this all here.

[ghost]

But it won't provide choice of secondary unlock mechanism. It will require fingerprint unlock and won't allow for nothing else. That's the problem everyone's getting at. Plus perhaps attack surface increase with direct boot).

[xbtc-im]

That's my opinion too ... If i turn the phone off, it should stay off and /data should stay encrypted until i explicitly unlock it. I don't want the phone to receive calls or do anything with /data until i input the decryption password ... But it seems Android is going into a different direction

[thestinger]

But it won't provide choice of secondary unlock mechanism. It will require fingerprint unlock

The fingerprint scanner is there and using it doesn't add inconvenience so it might as well be used, and we're going to use it. It doesn't even matter if it barely adds any security over just a PIN.

[thestinger]

Plus perhaps attack surface increase with direct boot

It barely increases attack surface... and it permits updates before the first unlock which is more important.

If i turn the phone off, it should stay off

If you turn it off, it will stay off. I don't see the connection.

it should stay off and /data should stay encrypted until i explicitly unlock it

Your user profile's data does stay at rest, other than nearly non-existent apps opting into using device-encrypted storage which could be optional. As I said before, it also finally brings the needed infrastructure to keep most data at rest while locked. Most phones are almost always on, idle and locked, not off, so that's what will actually matter the most.

But it seems Android is going into a different direction

If we didn't think it was the right direction, we would still be using FDE. If you don't agree with our design decisions you don't have to use the OS.

And again:

I don't really see the point of rehashing this all here.

[thestinger]

Before Pixels, there was an unencrypted /cache partition that was actually used. Now at least, there's device encrypted storage for that. We're in control of which stuff is device encrypted vs. credential encrypted and it will be giving us the crucial feature of actually protecting data while locked which is more important than any of the other trivialities involved. It already allows user profiles to become at fully at rest since they have different keys but most people don't leverage those...

I'm not getting how this is a good place to argue about this though.

[xbtc-im]

If you turn it off, it will stay off. I don't see the connection.

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.

it also finally brings the needed infrastructure to keep most data at rest while locked

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.

If we didn't think it was the right direction, we would still be using FDE. If you don't agree with our design decisions you don't have to use the OS.

You are absolutely correct. Nobody forces anyone to use the OS.

I'm not getting how this is a good place to argue about this though.

Right. You have made it clear that this will probably never be implemented, Maybe this should be on reddit instead :)

[thestinger]

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.

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.

[TimFW]

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.

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.

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.

[ghost]

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)? I couldn't find any information on this in my search engine.

[xbtc-im]

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. Probably right now the easiest attack would be to simply switch the phone with an identical one running modified software and let the target enter the passwords :)

[thestinger]

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 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.

[thestinger]

However keys HAVE been extracted from the TEE before, but for newer devices they also depend on the password

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.

[thestinger]

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.

[TimFW]

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 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?

[thestinger]

It would be a PIN / password with the user choosing the length just like a normal one.

[TimFW]

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!!

[kuleszdl]

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:

https://blogs.fsfe.org/kuleszdl/2018/03/31/securing-copperheados-by-using-separate-encryptionlockscreen-passphrases/

Maybe this might be a temporary solution for some of you until the "fingerprint + PIN" 2FA discussed here gets implemented.

[thestinger]

You're posting inaccurate information there.

[kuleszdl]

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.

[thestinger]

Unfortunately, with the move to Android 7 (or 8 ) this support was abandoned.

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.

On the other hand, using a short passphrase or simple PIN is insecure, because if an attacker succeeds to read your key from the (unauditable) TEE, it is trivial to get the key using brute force attacks.

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.

While a huge con of CopperheadOS is that all devices currently supported heavily rely on vendor blobs instead of on auditable free firmware

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.

If you value “vendor-based” security

Again the with the FUD.

[thestinger]

@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.

[kuleszdl]

@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

CopperheadOS only supports Nexus devices and there are no plans to expand device support beyond the Nexus/Pixel line.

Since you previously stated that "Nexus and Pixel phones also aren't the only targets supported by CopperheadOS." I assume the README is outdated?

[thestinger]

I think there are different arguments for and against general aspects of auditability and security of free vs. proprietary software/firmware

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.

Same goes for the Android vs. other systems topic.

If the 'other system' is traditional desktop Linux there's not much of an argument to make.

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.

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.

Since you previously stated that "Nexus and Pixel phones also aren't the only targets supported by CopperheadOS." I assume the README is outdated?

The bugtracker README is incredibly out-of-date. I'll just remove most of it.

[thestinger]

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.

[kuleszdl]

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.

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).

[thestinger]

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).

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.

Since Nexus 5 is already EOL for you

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.

and the support for the 5X will end pretty soon

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.

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

No, we're not going to reduce security for our users by publishing userdebug builds signed with the same keys.

as the Nexus' bootloader rejects flashing older builds (I assume upstream introduced it due to the "initroot" Nexus 6 vulnerability).

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 (adb reboot bootloader) doesn't allow flashing at all when the bootloader is locked.

[thestinger]

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.

[thestinger]

Pretending otherwise would be dishonest and we don't claim that it's a security feature.

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.

[kuleszdl]

No, we're not going to reduce security for our users by publishing userdebug builds signed with the same keys.

Good point, and you are right - this only works for private builds - didn't fully think about that.

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.

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?

Maybe some day someone will audit the publicly available CopperheadOS sources and report their findings to us. That day hasn't happened yet.

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.

In fact, the licenses we used made it nearly impossible to earn revenue and continue the project.

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.

[thestinger]

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.

[thestinger]

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.

[thestinger]

Migrated to the new issue tracker: https://github.com/GrapheneOS/os_issue_tracker/issues/28.