LockScreen updated (1.16)

I’ve uploaded a new build of LockScreen to !Store – version 1.16.

This update fixes a couple of bugs, and allows you to skip the various “pauses to display information” by clicking the mouse or pressing return.
For example, if you’ve set it to display last-login information (logging) when you log in, it’d normally pause for a couple of seconds to let you read that information. You can now click anywhere or press return (ie. once at the end of your password, then immediately again, which is a useful trick) to skip past if you’re in a hurry.

For those unfamiliar with LockScreen, it arose out of two projects which required a way of restricting access – security for remote database server boxes and the new ARMbook laptops. The program can “lock” the screen when the computer is idle or unattended, or on demand, and/or at startup. It shows pretty pictures when doing so, and provides date/time feedback when locked, and is generally an attractive way to protect your computer. LockScreen prevents most (all?) common tamper mechanisms such as alt-break, F12, ctrl-breaks etc, but we don’t make any wild claims for security – like most things, if a hacker has unrestricted access to the computer, they can probably find ways round. However, we can say that during development, we locked ourselves out of the computer on more than one occasion, forcing a restart. Fortunately we didn’t enable it at startup yet!

Essentially, LockScreen is designed to present a barrier that prevents access to a locked system, via encrypted password. You can provide a password hint if you forget. It integrates with !Boot and !Configure for a seamless experience, and is designed to look attractive in use.

LockScreen is especially important in an era of GDPR. It is a requirement of GDPR that any company, club, church, organisation etc that stores any form of personal information (names, addresses, email address, text conversations etc) take reasonable steps to secure that information. Placing a password on access is a basic requirement, and LockScreen is designed to fulfil this role elegantly.

LockScreen is available on !Store for all RISC OS machines (RISC OS 4.xx, 5.xx, and 6), and a version is also integrated into the software suite provided with every ARMbook.

important in an era of GDPR

I wrote a really long post (that I’ve since deleted without saving because I don’t want to be seen to be attacking your product). So instead I will say: please don’t say this

GDPR requires protection of the data (not the machine), and RISC OS fails in so many ways it isn’t funny – once you are in the machine, you’re in, and getting in is trivial. It’s game over if there’s something that is supposed to be confidential.
To give a stark comparison, my phone (Samsung S9) asks me for my password when it starts up. Like right at the beginning. The reason for this is that my password is used to encrypt the entire contents of the internal filesystem. The simplest way to secure my data is to just turn my phone off (long hold power, tap the Off icon, takes about five seconds). Then, without my cooperation, you don’t get to my data. Even opening the phone up and removing the flash chips and reading out the data won’t find you anything other than gibberish.
And that’s a consumer level smartphone, not some spycraft stuff you’d expect to see mentioned in a Clancy novel.

There are many good reasons for LockScreen. I just don’t think GDPR is one of them as… Well… RISC OS comes from an innocent era where people being nefarious usually meant they were being dicks over Econet, a networking system that was happy to shove passwords on the wire in cleartext. Or making a virus that periodically claimed 1K from the RMA until the machine died because, yeah, did RMTidy ever actually work?

Let’s list some things where a program like LockScreen would be useful:

• Children that like fiddling with stuff but aren’t smart enough to know what they’re breaking (cough, me as a child then…)
• That friend, you know the one, who thinks it is funny to replace your backdrop with some sort of porno so horrible that it makes you feel physically ill
• Times when you’re distracted and your computer is accessible. I’d imagine it would be a boon at shows, to say “hands off this one”.

That’s a fair point, Rick (and I largely agree with your points), but nevertheless most RISC OS users do use their computers for storing information, and therefore if GDPR applies (ie. what I said in my post), they need to take steps prevent access to data. LockScreen offers a level of protection for this, in much the same way as your smartphone startup screen does, and takes steps to prevent most of the normal non-screwdriver bypass vectors (I’m not claiming 100%, nor going to detail in a place where someone can search for “lockscreen” to see bypass tips(!), but email me and we can talk – I’m open about the pros and cons of LockScreen).

However, if you a) know it is a RISC OS machine, and b) know some tricks, there’s always going to be a way round, just like you can hack a Windows machine with the right tools and physical access (OK, bitlocker excluded, maybe). This is a major reason why LockScreen doesn’t identify itself or the operating system in its locked state. It is also why I don’t make any claims to be super-secure and question anyone who does.

Note – LockScreen is not a file encryption tool, and that aspect of GDPR would need to be handled elsewhere (and it has been thought about/discussed/planned). RISC OS doesn’t offer drive-level encryption, so we have to work with what we have. A hacker presented with a LockScreen-protected machine (I hope/believe, but cannot guarantee) would have a hard time gaining access, short of physical-level attacks with a screwdriver.

I have discussed with several people here at ROD about implementing further CMOS-based security measures to further lock things down from OS initialisation, although that is currently awaiting further action (limited programmer time). If you recall, some nasty bugs in FSlock got fixed this summer because of this work.

That’s a fair point, Rick (and I largely agree with your points), but nevertheless most RISC OS users do use their computers for storing information, and therefore if GDPR applies (ie. what I said in my post), they need to take steps prevent access to data.

I think the legislation states that you should take steps to protect data without specifying the level of protection.
The legislation does repeatedly refer to “appropriate technical and organizational measures” of personal data security.

The question then is what is appropriate? Is ‘encryption’ the correct term for a simple rotate of the bits in a byte of data?
From the genuine user data recovery after a hardware failure point of view, is it insane to encrypt using a unique signature of a specific hardware set?

Yes, Rick has a point that LockScreen isn’t a means of producing GDPR compliance. It’s part of a set of features that could produce GDPR compliance. I’m not sure full disc encryption is required, but data encryption would be a reasonable assumption. GDPR only concerns itself with the data you store, not the OS/Application suite used to make it visible to someone.
Perhaps on this element people should be thinking of ensuring the OS does not allow casual data storage in the OS location (dare I say “partition”?)

Yes, Andrew has a point that encrypted data, or not, if an unauthorised person can walk up and poke keys on a temporarily unattended and already logged on machine to retrieve data then it isn’t GDPR compliant.
A handy feature on this would be an RFID and PIN which meant you could unlock with a PIN (when the RFID was on your person) and the machine auto-locks when you walk away.

Taken to Aldershot

Rick reminisced

Econet, a networking system that was happy to shove passwords on the wire in cleartext

And indeed where the fileserver stored the current passwords at a known address in RAM without peek protection.

Steve clarified

the legislation states that you should take steps to protect data without specifying the level of protection.

And under US law, any process that is undertaken to “encrypt” the data is illegal to circumvent no matter how utterly trivial that “encryption” is… e.g. the “encrypted” fonts in the XPS file format that merely have the first few bytes EORed with their own leafname. Doesn’t matter if you know the algorithm, doesn’t matter if you could decode it with paper and pencil, if it has been “encrypted” then it is illegal to circumvent it.

The only thing this level of protection saves you from is the Daily Mail headline “Laptop left on train wasn’t even password protected”.

It is Security Theatre. A lockscreen is for discouragement, not protection (and there’s nothing wrong with that).

GDPR requires protection of the data (not the machine)

It can be the machine. For example with an encrypted filesystem.
Of course, because (of the lack of) this, it’s basically impossible to use RISC OS and be GPDR compliant.
IMHO, encryption, with a password at boot, should be a bounty. It’s not so difficult to do… and could even use a second core.

without specifying the level of protection

It does. It’s not “appropriate technical and organizational measures” but “all the appropriate technical and organizational measures”.
If it can be proved that an easy solution could have blocked a data breach… you have a problem.
And encryption is REALLY an easy way to protect computers against unwanted physical accesses.

all the appropriate technical and organizational measures

It goes further than that. This PDF covers the encryption algorithms that are considered acceptable: FIPS 140-2

Yes, because it’s appropriate and feasible.
GDPR is a ‘if you could do it, you should do it’.