Frequent unlock use case for Librem 5 and 11

Hardware
1

Hi all,

I have a real-world use case I’m working towards, and would like some help with setting out on the right foot.

TL;DR - I need a reliable method of unlocking both the Librem 5 and the Librem 11 very frequently; every few minutes or so over several hours at a time. Security requirement is relatively low.

I have a Librem 5 to experiment with, and my skill level is mediocre - you could say experienced and fairly capable, but not a programmer by any stretch of the imagination.

The use case is a small mobile business inspecting and servicing equipment. We currently use Apple, with a FileMaker solution which we custom made for this purpose about a decade ago running on iPads. The Filemaker solution was light years ahead of its time, has been excellently maintained, and we are still running Ok on it, but is showing its age a little now and will soon be a no-go for reasons I won’t expound on here. I’m trying to stay ahead of the curve and get moving toward a replacement system before we really need it, and the dream I would love to pursue is Linux based, preferably Debian. (Off-topic suggestions welcome for low-code systems compatible with Debian/PureOS…!)

Part of the routine of servicing and inspections and general business involves referring to a database for technical information, and working through check-sheets, etc. This involves (very) frequently unlocking the device. Battery life is still vital though, so leaving the screen unlocked is not really an option, and poking in a passcode has driven me crazy in years gone by. Apple’s Face ID is currently saving us thousands of dollars in time saved not mucking around with passcodes, especially with work gloves on which make touch screens more difficult.

The best idea I have come across so far is the concept of using BlueProximity software with a Bluetooth keychain finder or similar device for unlock, and a short delay for automatically re-locking the screen. Again, this is not a high-security scenario, but simply needs to be a reasonable balance of reliability, convenience and security, so we can get work done in the real world with a low risk of being taken advantage of by bad actors or opportunists.

I have watched Purism’s development for years, and was really hoping both the Librem 5 and the new Librem 11 would have NFC hardware for this reason, but ‘tis not to be. This lock / unlock problem is really the first big hurdle for me to conceive of actually integrating PureOS into our daily business use. There are many more challenges to actually realising full replacement of Apple and Windows for us, but it is definitely and reasonably achievable.

Sorry that’s a little long!

  • Have you used a Bluetooth proximity unlock system with PureOS, or the Librem 5 specifically?
  • Do you have any better or alternative unlock suggestions for this use case?

Thanks in advance for your thoughts.

1 Like
2

One solution is to configure Phosh to only make you login after a certain amount of time of inactivity and to shorten the password from 6 to 4 numbers (or 3 characters). BTW, Phosh is the interfaz used in both the L5 and L11. You might want to check out this thread:

3

No, I never use Bluetooth for any of my electronic devices anymore; I am slowly working on a solution to use cables for everything instead.

Your root issue is the battery, so the most convenient solution is to use a power bank. Whenever you decide to get the Librem 11, get at least two power banks for both devices for high reliability; recharge them once business hours are over.

1 Like
4

Thanks for the replies.

I’m hoping for a reasonable balance here. I don’t want to eliminate passwords, but rather use some alternative system to lock and unlock the display - reduced absolute security, to be sure, but reduced in the right way.

I’m not hung up on Bluetooth per se, as I’m well aware of some of the security implications there, but real-world security is strongly tied up with physical access. For example, plugging in a physical USB-C key instead, becomes like leaving the key in the lock of your front door. Not smart, to say the least. And while physical security is undoubtedly better, if you made it a momentary system, then you have another problem: having to cycle a physical port ≈ 1.5 million times over a three year lifespan of a device. Also also not a feasible idea; not to mention inconvenient.

Out there in the industry, it is common to use secured wireless systems to protect, for example, the remote controller used by a Hiab crane operator, or a set of truck columns. The security requirements here are much more similar to the use case in question than, say, a journalist in a foreign country. For that purpose, I would absolutely say (vetted) physical cables only please!

Hence my interest in wireless “fob” style unlocking technologies. It is also worth noting here that the Librem 5 is unique in allowing the user to physically kill the Bluetooth module, along with all other comms and sensors if required.

Would it be a better idea to use a Wifi network broadcast from the work vehicle on site? Or another method? All ideas welcome. =) I’ll consider physical systems too, but it really does have to be reasonably practical…

5

If you are going to frequently be in close proximity to your devices and unlocking them, I hardly see a need for more security; you do not have a clearly defined threat model.

If you able to explicitly define the capabilities of these bad actors or opportunists, specify them. What are you exactly trying to protect? How much time do they realistically have before their actions are detected by you?

6

The following proposal may not be possible, is not practical if it is, and I am spitballing an idea:

Perhaps a savvy dev can look into using the breakout board for the Librem 5 (based on the spec, it seems like it could support NFC) and solder a separate NFC reader. From there, The Librem 5 could be programmed to use FIDO2 to unlock it similar to Nitrokey’s demo here: Streamline Employee Attendance Tracking With Nitrokey, FIDO2 and Odoo | Nitrokey

I know you mentioned not wanting to insert a security key into the USB port, though using PAM and U2F appears to be an option to accept the key or a password: 19.04 - Passwordless login with Yubikey 5 NFC - Ask Ubuntu

1 Like
7

How about Bluetooth unlock? I know MacBook can be unlocked with an Apple Watch that is in the area sharing a security token using bluetooth, I wonder if that is a good method. On Sailfish there was a program that allowed you to use Bluetooth unlock for a computer.

8

Voice unlock?

Not tremendously secure but is hands-free and does provide a barrier to the casual intruder i.e. intruder can’t just walk up to an unlocked, unattended device and start using it. (Intruder can of course just walk up and walk off with the device - so that’s where it requires understanding your threat model.)

Otherwise, yes, something wireless e.g. Bluetooth / NFC / Zigbee.

9

Great thoughts thanks all.

To be perfectly honest @FranklyFlawless , no, we don’t have a very well-defined threat model (yet). Remember, this is a small business, not a corporation with full-time positions dedicated to IT security. We do have a work-in progress threat model, albeit a fairly humble one. The most vulnerable threat identified at the moment is simply the opportunist walking off with the physical device - remember, this is a mobile service scenario in the open public. We already have good mitigation policies in place to help retain devices, and of course none of this is to say good standard practices are unconsidered here. (Hence my having enough misgivings about the Bluetooth concept to open this thread)

Thanks for your excellent thoughts @gondolyr, I didn’t realise the breakout board was available. Although I doubt it, I’ll be very interested to see if there is space for NFC or a specialist comms chip non-externally…

Edit: I’m not totally against the concept of occupying the USB-C port with a compact dongle, say for a more locked-down ‘closed loop’ network, think vehicle unlock fobs, for example, as this would be removed at the end of the job / for charging / etc.

10

I came across PN532 NFC RFID module V4 - ELECHOUSE but I have no clue if this would even work with the breakout board. I unfortunately have practically no knowledge when it comes to DIY electronics.

11

Then your security will depend on how often you frequently check your device, and your proximity to it as a deterrence. The more frequent and close you are, the harder it will be for an opportunist to succeed in their objective.

12

Use the accelerometer coupled with the proximity check to activate an alarm?

1 Like
13

Now that is a smart thought!!

14

Not if you also carry the device around too: it cannot differentiate between you and an opportunist.

15

That is the purpose of the proximity check.

Anyway, I’m sure these days Google has everyone’s gait on file and the accelerometer by itself is enough. /joke

1 Like
16

I suppose once it left range the alarm would still sound, so that combination is at least decent, if not a fair compromise for the use case.

The usability of such a system would certainly overcome the usual ‘security friction’ for uptake anyway.

17

Well then the next step is an actual implementation.

18

Agreed.
I’ll most definitely post here with any prototypes and final working models we end up implementing.
At this stage I like the idea of a hybrid approach; using a USB-C plug-in dongle, running a closed and secured ‘external’ authentication network. At a glance it seems to me to be the best of most worlds, while still being fairly practical. This approach should also reduce the gap between theorising and actual implementation.

Any further ideas for existing products in this vein?

1 Like
19

Releasing your implementation under a gratis and libre open-source license would be appreciated, so it can be improved over time by others.

20

Once you overcome the the lack of NFC(*) on the Librem 5, you should be able to set up PAM (Pluggable Authentication Modules) to fit your scenario. Using the pam_timestamp module you can make the pin entry valid for a configurable time and still require using a Yubikey on every unlock.

I think a starting point for your PAM stack could look something like this:

auth required   pam_u2f [...]
auth sufficient pam_timestamp.so timestamp_timeout=600 verbose
auth required   pam_unix.so

session required pam_unix.so
session optional pam_timestamp.so

The timeout is given in seconds, adjust for your convenience/security threshold.

Note that the security key check has to happen before the password check, which is probably backwards for most people and may take some getting used to. This is because pam_timestamp tracks successful logins, not the success of individual factors in the stack. Done this way, the security key is always checked, but the password prompt is bypassed by previous logins within the timeout period.

I have not tried this, so you may need to do some experiments and man page reading…

(*) Of course, this should work equally well over the USB-C port, but I understand you would prefer NFC to avoid wear on the connector.

1 Like