Plymouth needs a safe method to unlock the device on boot without a physical keyboard.

[Tudor Holton]

My tablet is encrypted, and I'm presented with the plymouth decryption screen during every boot. However, there is no onscreen keyboard, causing me to have to dig out a keyboard just to start the machine.

I'd imagine as this goes along we're going to get more and more keyboardless devices. Windows has already solved this.

I disagree with the comments in bug https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/1239004 which is closely related to this.

The simplest way is to implement an onscreen keyboard. Obviously, it would have to support everything that could be in a physical keyboard, tho, or people could lock it with a physical keyboard and then find they can't unlock it with an onscreen one due to a missing symbol.

Another idea would be not to use a keyboard at all. We could instead use:
(a) a USB key (which has the (dis)advantage of being crackable programmatically)
(b) a sequence of vectors, like phones do (but there's a security risk since on some screens you can see the mark where it's been done repeatedly)
(c) a voice print (fakeable)
(d) a voice password (security risk due to being heard)
(e) a camera image (also fakeable)
(f) randomised visual word ordering with decoys and fail2ban scenarios.

I believe that the safest and most reliable way is simply to use an onscreen keyboard, however, creating an encryption hook into plymouth could allow other methods to be used. (f) could also work, tho and may be considerably easier to implement.

[Launchpad Janitor (janitor)]

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

[Harrison S (htsmi)]

This affects the practicality of Ubuntu as an operating system on my Dell Venue 8 Pro. Encrypting just the home directory is not really a satisfactory alternative, nor is carrying a USB keyboard at all times. I found this:

https://github.com/zrafa/onscreenkeyboard

as a rudimentary example of what could be implemented as a quick hack. I don't have the experience to modify it in a very helpful way, but in my tests, if I set MOUSEFILE in osk_mouse.c to "/dev/input/mice", I am able to _somewhat_ control it via the touchscreen – emphasis on "somewhat".