Kill Switch PR

[sigenc]

Hello thestinger,

would you accept a PR that incorporates a kill switch into the OS? Or maybe like the app LOCKER.

My idea is to have a timer set to whatever is needed and if you didn't log in succesfully into your device at that timeframe, it deletes the encryption keys. So basically you cannot be forced to reveal you real password, cause it would be plausible that it can't open any files anymore.

Edit: This has to function even when the phone is shutdown and on the first boot it should recognize that it wasn't open succesfull in the timeframe.

[thestinger]

My idea is to have a timer set to whatever is needed and if you didn't log in succesfully into your device at that timeframe, it deletes the encryption keys. So basically you cannot be forced to reveal you real password, cause it would be plausible that it can't open any files anymore.

It's common for invalid password entries to happen by accident and it's critical to avoid accidental data loss. A feature able to cause accidental data loss like this certainly couldn't be enabled by default and if it's too risky, it can't even be offered as an option. Our focus is on features that can be enabled by default or that can at least be highly recommended if they require opt-in.

There may be features like this that are desirable, but many can already be implemented via device managers on the Pixel phones and any future devices due to file-based encryption. An app can opt-in to being Direct Boot aware and can explicitly mark files as device encrypted to make it available before the first unlock.

However, there's lower hanging fruit than this. I don't want to have issues filed about further work in this area until #451 is implemented. Fingerprint unlock makes using a strong encryption passphrase substantially more convenient and a PIN as a second factor would avoid weakening security at all vs. using a PIN as the primary unlock method. It also isn't really any less convenient, and the fingerprint scanner is often actually more convenient than the power button. It already has restrictions too: 48h timeout which could be made configurable later, and it can't be used for the first unlock.

[thestinger]

My idea is to have a timer set to whatever is needed and if you didn't log in succesfully into your device at that timeframe, it deletes the encryption keys. So basically you cannot be forced to reveal you real password, cause it would be plausible that it can't open any files anymore.

It's common for invalid password entries to happen by accident and it's critical to avoid accidental data loss. A feature able to cause accidental data loss like this certainly couldn't be enabled by default and if it's too risky, it can't even be offered as an option. Our focus is on features that can be enabled by default or that can at least be highly recommended if they require opt-in.

There may be features like this that are desirable, but many can already be implemented via device managers on the Pixel phones and any future devices due to file-based encryption. An app can opt-in to being Direct Boot aware and can explicitly mark files as device encrypted to make it available before the first unlock.

However, there's lower hanging fruit than this. I don't want to have issues filed about further work in this area until #451 is implemented. Fingerprint unlock makes using a strong encryption passphrase substantially more convenient and a PIN as a second factor would avoid weakening security at all vs. using a PIN as the primary unlock method. It also isn't really any less convenient, and the fingerprint scanner is often actually more convenient than the power button. It already has restrictions too: 48h timeout which could be made configurable later, and it can't be used for the first unlock.

[sigenc]

@thestinger

Thx for the fast answer. I did come up with the idea, because of people being hold into custody for not revealing there passwords. There is no other solution than to make the device clean the keys, so even with the correct pass you can't decrypt it anymore. There are people in the uk jailed, that can't remember the pass and are waiting for a trial. The judges don't believe them, that they can't remember the correct pass. I'm not talking about criminals, more of innocent people. This kind of kill switch would prevent them from holding this people in custody.

I understand, that you are interested in preventing data loss. But if this would be an opt-in, people have to be carefully with what they do. I know that device manager apps are capable of doing what i have in mind.

So basically we have to implement 2 factor auth first. I have a friend that is really into your OS and would like to help with some features.

@ethicstechOSS

Maybe i can convince ethicstechOSS to help out with the 2 fac. Let's see how much Money they want.

Thank you

[sigenc]

@thestinger

Thx for the fast answer. I did come up with the idea, because of people being hold into custody for not revealing there passwords. There is no other solution than to make the device clean the keys, so even with the correct pass you can't decrypt it anymore. There are people in the uk jailed, that can't remember the pass and are waiting for a trial. The judges don't believe them, that they can't remember the correct pass. I'm not talking about criminals, more of innocent people. This kind of kill switch would prevent them from holding this people in custody.

I understand, that you are interested in preventing data loss. But if this would be an opt-in, people have to be carefully with what they do. I know that device manager apps are capable of doing what i have in mind.

So basically we have to implement 2 factor auth first. I have a friend that is really into your OS and would like to help with some features.

@ethicstechOSS

Maybe i can convince ethicstechOSS to help out with the 2 fac. Let's see how much Money they want.

Thank you

[thestinger]

It doesn't prevent jailing them for destroying evidence.

[thestinger]

It doesn't prevent jailing them for destroying evidence.

[sigenc]

They are not activily destroying evidence. To accuse somebody of destroying evidence it has to be an active part involved. It is even not known for a fact that there is any evidence on the devices. You can be kept in custody for as long as they want in the uk. This means 10+ years. You won't get 10+ years for destroying evidence.

[sigenc]

They are not activily destroying evidence. To accuse somebody of destroying evidence it has to be an active part involved. It is even not known for a fact that there is any evidence on the devices. You can be kept in custody for as long as they want in the uk. This means 10+ years. You won't get 10+ years for destroying evidence.

[thestinger]

So entering a wipe password would be actively destroying evidence but a countermeasure doing it automatically wouldn't be?

[thestinger]

So entering a wipe password would be actively destroying evidence but a countermeasure doing it automatically wouldn't be?

[sigenc]

Yes

[sigenc]

Yes

[thestinger]

If you want features like this to be worked on, you'll need to find someone willing to work on them first. It can be for Android in general, it doesn't need to be specific to CopperheadOS. There's a lot of lower hanging fruit though. There's not much point in filing feature requests right now. There isn't even an obvious candidate for us to hire, short of poaching someone from Google (unlikely), since no one else is working on any robust / serious Android security improvements outside of Google.

[thestinger]

If you want features like this to be worked on, you'll need to find someone willing to work on them first. It can be for Android in general, it doesn't need to be specific to CopperheadOS. There's a lot of lower hanging fruit though. There's not much point in filing feature requests right now. There isn't even an obvious candidate for us to hire, short of poaching someone from Google (unlikely), since no one else is working on any robust / serious Android security improvements outside of Google.

[sigenc]

Yes i understand that situation. In the end of july i will talk to a friend, who has some good programming skills and will ask him to lay out a concept for this. But i first need to know if such a pr would be accepted. Cause i will have to pay him.

THX

[sigenc]

Yes i understand that situation. In the end of july i will talk to a friend, who has some good programming skills and will ask him to lay out a concept for this. But i first need to know if such a pr would be accepted. Cause i will have to pay him.

THX

[thestinger]

It can't bypass anti-theft protection, so it can't allow wiping without authentication. That's also dangerous as I mentioned (accidental input, kids). A wipe password might be acceptable, depending on the design and rationale. There needs to be a convincing argument for having it and the design needs to match the rationale.

[thestinger]

It can't bypass anti-theft protection, so it can't allow wiping without authentication. That's also dangerous as I mentioned (accidental input, kids). A wipe password might be acceptable, depending on the design and rationale. There needs to be a convincing argument for having it and the design needs to match the rationale.

[thestinger]

And I'd be more interested if there wasn't a lot of lower hanging fruit. Also keep in mind features need to be ported to future Android versions. If I don't see it as important then it gets lost as soon as it's a non-trivial porting job.

[thestinger]

And I'd be more interested if there wasn't a lot of lower hanging fruit. Also keep in mind features need to be ported to future Android versions. If I don't see it as important then it gets lost as soon as it's a non-trivial porting job.

[sigenc]

I tested the locker app and it worked perfectly on my Nexus 6p with copperheados. It doesn't have a timer but after 3 attempts with the wrong pass it wiped the data.

https://f-droid.org/repository/browse/?fdfilter=X&fdid=net.zygotelabs.locker&fdpage=6&fdstyle=grid

[sigenc]

I tested the locker app and it worked perfectly on my Nexus 6p with copperheados. It doesn't have a timer but after 3 attempts with the wrong pass it wiped the data.

https://f-droid.org/repository/browse/?fdfilter=X&fdid=net.zygotelabs.locker&fdpage=6&fdstyle=grid

[thestinger]

At the lockscreen, it won't work at the pre-FBE boot screen or with pre-unlock FBE. It also bypasses anti-theft + is dangerous. Need a different design. Only working with FBE is fine but that doesn't really work with either.

[thestinger]

At the lockscreen, it won't work at the pre-FBE boot screen or with pre-unlock FBE. It also bypasses anti-theft + is dangerous. Need a different design. Only working with FBE is fine but that doesn't really work with either.

[sigenc]

So the device admin api doesn't work outside of FBE?
My concept would be to have the possibility to use the functions of locker with another option to use a timer and a wipe Password.
I was under the impression device admin apps can be run outside of FBE.

What is dangerous about bypassing anti-theft? Where is the Advantage of this anti theft in android. Isn't it only usable with Google account?

[sigenc]

So the device admin api doesn't work outside of FBE?
My concept would be to have the possibility to use the functions of locker with another option to use a timer and a wipe Password.
I was under the impression device admin apps can be run outside of FBE.

What is dangerous about bypassing anti-theft? Where is the Advantage of this anti theft in android. Isn't it only usable with Google account?

[thestinger]

So the device admin api doesn't work outside of FBE?
My concept would be to have the possibility to use the functions of locker with another option to use a timer and a wipe Password.
I was under the impression device admin apps can be run outside of FBE.

I didn't say that. I said it won't work for the boot password screen on pre-FBE devices. It would need to be made Direct Boot aware to work before the first unlock for FBE. Regardless, an app is the wrong way to do it for other reasons. I'm just pointing out that the app you're pointing to doesn't really work.

What is dangerous about bypassing anti-theft? Where is the Advantage of this anti theft in android.

The device can be stolen and wiped. Anti-theft protection provides a form of herd immunity against theft and encourages return of the device for a small reward since there's no easy way to use it for anything but scrap otherwise.

Isn't it only usable with Google account?

No, CopperheadOS makes it work without Google Play Services.

[thestinger]

So the device admin api doesn't work outside of FBE?
My concept would be to have the possibility to use the functions of locker with another option to use a timer and a wipe Password.
I was under the impression device admin apps can be run outside of FBE.

I didn't say that. I said it won't work for the boot password screen on pre-FBE devices. It would need to be made Direct Boot aware to work before the first unlock for FBE. Regardless, an app is the wrong way to do it for other reasons. I'm just pointing out that the app you're pointing to doesn't really work.

What is dangerous about bypassing anti-theft? Where is the Advantage of this anti theft in android.

The device can be stolen and wiped. Anti-theft protection provides a form of herd immunity against theft and encourages return of the device for a small reward since there's no easy way to use it for anything but scrap otherwise.

Isn't it only usable with Google account?

No, CopperheadOS makes it work without Google Play Services.

[sigenc]

Ok. Thanks for the answer. We will do a concept and come back to you.

[sigenc]

Ok. Thanks for the answer. We will do a concept and come back to you.

[Kamkata]

Hello stinger,

i came across a post from you on reddit. https://www.reddit.com/r/CopperheadOS/comments/8coubp/copperheados_reviewed_in_2600/dxhqy3q/

maybe you can think about a app that has device admin rights and can provide this dead man Switch.

[Kamkata]

Hello stinger,

i came across a post from you on reddit. https://www.reddit.com/r/CopperheadOS/comments/8coubp/copperheados_reviewed_in_2600/dxhqy3q/

maybe you can think about a app that has device admin rights and can provide this dead man Switch.

[thestinger]

Yes, this could be an app, but we don't have time to develop one ourselves right now.

[thestinger]

Yes, this could be an app, but we don't have time to develop one ourselves right now.