Enable encryption as per design mock up

Status changed to 'Confirmed' because the bug affects multiple users.

The fix for this bug is rather small for Ubuntu System Settings. Targeting canonical-devices-system-image since I am unsure in which component the majority of the work will take place.

right, as the previous comment suggested, most of the work is not to "enable" encryption, but to have an encryption solution implemented than we can enable/disable then

this is not planned near term

Hi, any updates on a timeframe for implementing this?

until this lands, Is there a workaround to at least encrypt personally identifiable information (PII)?

I am also very interested on this!

Currently, I have a brand new iPhone and I'll not move to Ubuntu Phone until it comes with encryption by default.

This is VERY important.

There is no workaround. This is on the feature wishlist but no firm date yet, thanks for the feedback on priority.

This is essential, especially if it has plans to be a convergence device.

Not having this is so 1990. This is a GIGANTIC part of the ubuntu phone sales pitch. I wish I was able to help more than just supporting this but hopefully this comment helps. Please encrypt!

This is a MUST to have, should be a priority.

Nevertheless, is it possible to enable encrypted home dir on Ubuntu Phone?
I would be happy with it.

Like: "adduser --encrypt-home me"

I don't mind, for now, to encrypt the entire device.

On 20 February 2016 at 19:17, wayne <email address hidden> wrote:

> Not having this is so 1990. This is a GIGANTIC part of the ubuntu phone
> sales pitch. I wish I was able to help more than just supporting this
> but hopefully this comment helps. Please encrypt!
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1464697
>
> Title:
> Enable encryption as per design mock up
>
> To manage notifications about this bug go to:
>
> https://bugs.launchpad.net/canonical-devices-system-image/+bug/1464697/+subscriptions
>

I too would like to see encryption on the tablet/phone. This is an important feature.

Also like to upvote this request.

Was kind of shocked full device encryption is not available on BQ Aquaris M10 Ubuntu tablet (even not in the long run, see bug 1446893) as this is already years available in regular Ubuntu (and of course now also in iOS, Android, BlackBerry, etc.). Did not expect this not to be present. Renders the device currently quite useless as I'm not willing to put personal information (e-mail, photos, etc.) on an unencrypted device.

I agree. It is important to have mmcblk0p23 (/userdata) & mmcblk1 (sdcard) encryption as well as working OpenVPN capabilities for safety.

BQ M10 doesn't encrypt my data and isn't able to read my external HD (ext4, encrypted). I am considering returning it because of this BIG fail.

I'm sure this has already been discussed, but perhaps if "most of the work is ... to have an encryption solution implemented than we can enable/disable" at will... then an appropriate solution would be to:

1. always encrypt the userdata partition
2. by default (or when the encryption option is disabled) the password is blank or well-known
3. when the option is enabled, we simply swap the insecure non-password for the user credentials ala cryptsetup luksAddKey and luksRemoveKey

This is similar to how new Nexus and iOS devices do it (though they do it with a hardware register), and has the benefit of clear-text bits "never hitting the platters" (so to speak).

The major downside (as I see it) is that you incur the cyrpto performance penalty even if the option is disabled, but this is partially offset by:

1. the fact that this setup *retroactively* protecting one's user data who *later* decides it needs to be protected,
2. using the fastest cipher these little ARMs can push (e.g. salsa20 if they don't have AES acceleration), and
3. being able to somewhat reliably guess (on inexpensively test) if the luks password is blank, like using [keyslot-7] if it's blank or using a low/fixed iteration-count (which could be tested against)

Great work thus far, guys!

Is anyone using an "unofficial" workaround at this time for the SD card?