GDPR

[taken to Aldershot, from Announcements]

where someone can search for “lockscreen” to see bypass tips(!)

That’s why I intentionally didn’t mention anything.

A hacker presented with a LockScreen-protected machine

Depends upon their familiarity with RISC OS. Some might think “riscos” is some weird Spanish incarnation of Debian for paranoid people. :-)

The legislation does repeatedly refer to “appropriate technical and organizational measures” of personal data security.

While the GDPR does not require encryption, the text repeatedly mentions it – specifically in articles 34 (notification to the user who’s data was stolen) where you are obliged to describe what measures were taken to protect the data in particular those [measures] that render the personal data unintelligible to any person who is not authorised to access it, such as encryption.
Article 32 (security of processing) states: […] the processor shall implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk, including inter alia as appropriate: (a) the pseudoonymisation and encryption of personal data.

Note well – the GDPR (having read it) is not that concerned with access to the machine, it is concerned with access to the data, because in this day and age you only need to get to the data once to be able to access it forevermore.

The question then is what is appropriate?

Case law will decide that. However the level of appropriateness will depend a lot on the nature of the data. For example, Andrew is going to have a client list with addresses, phone number, email. It may contain flags on products the clients have purchased (for update notifications) and maybe a flag for whether or not they want publicity mails.
This data is personal, but not especially sensitive. The ICO may decide that a simple password protection on the one machine that holds the data is sufficient.

On the other hand, records of bank card details, convictions, medical history etc – these may land big fines if the data is not encrypted because disclosure could be damaging.

Is ‘encryption’ the correct term for a simple rotate of the bits in a byte of data?

No.
It is commonly understood that “encryption” relies upon some form of “key”, such that you need the key (or to attempt to crack the datastream to determine the key, as is the case with WEP) in order to decode the data.
Rotating bits does not require any key, as such it is an encoding (akin to ROT13) and not an encryption.

I’m not sure full disc encryption is required,

No, I don’t think it is. I was simply pointing out the fact that such features are becoming commonplace in domestic smartphones.

but data encryption would be a reasonable assumption.

Yes. More and more you will see a little USB key stuck in the side of the computer, this isn’t for storage, it’s an encryption key to grant access to data. They use them at work, and doctors also use them for accessing the Sécu’s database. It isn’t a perfect system – as far as I can determine it restricts access to the data, but doesn’t control what happens once the data has been accessed (saved elsewhere, printed, etc). This is why the GDPR specifies “organisational measures” as well as technical ones, that of training staff accordingly.

on machine to retrieve data then it isn’t GDPR compliant.

This is where those USB keys come in useful. You don’t need to lock or shut down the machine, you just unplug the key and wear it via the neck strap. The machine can no longer access the data, so sitting at it won’t get anyone very far.
[it is hoped that software that uses encryption will notice the key disappearing and automatically quit; I know the medical stuff does because one of the intern doctors wore the key around her neck on a long braid, so when she got up to do something it yanked the key out and all the medical stuff instantly closed down leaving just the desktop and web browser]

One of the annoying things about the GDPR is that it is aimed at catching the big players abusing people’s digital rights (and doesn’t do a particularly good job of it as the likes of Google and Facebook still track you everywhere and many consent forms still say “third parties” rather than listing them and you still see opt-out boxes and “reduced features if you don’t agree”).
Meanwhile, the only concessions are that very small businesses don’t need to audit and log all accesses to restricted data, and data used for personal or household ends is exempt. That is to say, I can run a BBS, forum, or mailing list and process necessary information on people; but if I was running a sports club that charged a fiver a year for admin, then it’s a business and the full GDPR applies.

This is why ROOL and CJE both sent emails requiring me to consent to having my data held/used. They’re businesses, it applies, the end.

I can see what the basis is behind the GDPR, but like the cookie thing, it does SFA for those doing the most abuse while making life a pain in the ass for everybody else.

To put this into context, let’s look at The Daily Express. It doesn’t bother giving me any notification about cookies – probably because that’s a horrible nasty thing IMPOSED on hapless Brits by the UNELECTED European overlords… Instead it proudly proclaims “40 DAYS TO GO” in big letters, there was an actual counter but I don’t see it (not that I’ve looked, there’s only so much Express I can take before wanting to douse myself in vodka and lighting a match…).
Remember I said no cookie consent? That’s probably because they don’t want you to know about Grapeshot, ShareThrough, DoubleClick Ad Exchange Buyer, Twitter Advertising, Google Publisher Tags, Moat, Captify, Aggregate Knowledge, Gigya Socialize, Tealium, Google Tag Manager, OnTho.io, Index Exchange, Chartbeat, Scorecard Research Beacon, Google Analytics, and Facebook Connect.
PHEW! What a STUNNING list.
[that’s a joke for people that get Express articles in their Google News feed – they describe practically everything as STUNNING (usually in capitals)…I don’t think they know what that word means]

No, I don’t think it is.

It’s not, but this is an easy way to solve some GDPR problems.

Taken to Aldershot again…

It can be the machine. For example with an encrypted filesystem.

It’s never the machine. Why? Because it is completely possible for my phone to have an encrypted filesystem, for me to give a password to log in, and for my phone to then be “locked” with a simple swipe action, or maybe (as I did with my tablet because the lock screen is bugged) to disable locking entirely.
That file system is still technically encrypted, but the machine is then wide open.

GDPR is interested in access to the data itself. It matters not if the computer has twenty passwords and an encrypted filesystem if the data can be copied onto a USB key, left on a train, and contain all the information in clearly readable format. Not like anybody would be stupid enough to do such a thing…….

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.

Encryption of a filesystem might to something to think about, but forget about the boot password. It’s theatre.
Why? It took me about three minutes to break into a locked down XP box with nothing more than a CD ROM. Believe me when I say that it would take under a minute with only my smartphone to render the majority of RISC OS machines accessible.

Stop thinking about protecting the operating system and start thinking about protecting the data that it has access to. Passwords are only there to dissuade casual snooping and annoy the user. Filesystem encryption is better, but we run into a problem. If the filesystem is encrypted and it is “unlocked” when the machine is started, does this mean that it remains unlocked for the rest of the session? If so I can certainly see a useful case for LockScreen. All of the measures are, in themselves, parts of a bigger puzzle.

It does. It’s not “appropriate technical and organizational measures” but “all the appropriate technical and organizational measures”.

No, it’s not. Allow me to quote from section 1 paragraph 83: Those measures should ensure an appropriate level of security, including confidentiality, taking into account the state of the art and the costs of implementation in relation to the risks and the nature of the personal data to be protected.

What that is saying is that appropriate measures should be taken to protect personal data, however the level of measures employed can depend upon the nature of the data to be protected. A database that records that I’m a disabled transvestite ethnic immigrant Jew with a history of substance abuse and a long line of petty theft convictions ¹ is going to be a lot more damaging than a database listing my email address, and the degree of protection expected should reflect that. By all means, lock up my email address if you want, but between you and me, it’s a low grade piece of personal information so doesn’t warrant that much effort. The aforementioned pile of personal information does, and it should carry full access control and auditing.

If it can be proved that an easy solution could have blocked a data breach… you have a problem.

Possibly. Again the level of problem is going to be weighted against the nature of the breach, whether it was intentional or negligence, and the possibility of harm to those involved.

And encryption is REALLY an easy way to protect computers against unwanted physical accesses.

Depends. If the filesystem is unlocked as part of boot and then left in an open state, it’s not that much better than if it had never been locked at all.

The ideal solution is to have the specific sensitive data encrypted, with a requirement of a password for every access. We can (almost) do that already. Passworded archives. Not crypto secure (can be brute forced) but a lot better than nothing at all, and possibly enough for “typical user/client data” to satisfy the GDPR. All that is needed is to have the mindset of “forgetting” the archive when it is done with it, but perhaps better yet would be if SparkFS could auto-forget an archive of it hasn’t been accessed within a certain number of minutes (requiring password re-entry).

¹ disabled because we know how certain papers like to portray disabled people as scroungers, transvestite because the parents might not know, ethnic immigrant because everybody loves foreigners right now, Jew because they always get dumped on, and substance abuse and convictions because that sort of thing will engage people’s innate prejudices.

This PDF covers the encryption algorithms that are considered acceptable: FIPS 140-2

American, and oddly enough doesn’t mention “backdoor” even once.

https://www.theregister.co.uk/2019/07/25/encryption_fbi_boss/

Rick referred to SparkFS encrypted archives – not too good because ISTR they only use the first 6 characters of the password.

I would point out that Organizer has been able to encrypt part of all of its disc data since v2.26 in 2016, using either MD5 hash and IDEA encryption, or SHA1 hash and Blowfish encryption. A password is required to start it, and you can also easily Lock it so a password is required again to see any data. It does not control access to the machine or memory.

Stop thinking about protecting the operating system and start thinking about protecting the data that it has access to

That was what I was suggesting and…

I would point out that Organizer has been able to encrypt part of all of its disc data since v2.26 in 2016, using either MD5 hash and IDEA encryption, or SHA1 hash and Blowfish encryption. A password is required to start it, and you can also easily Lock it so a password is required again to see any data. It does not control access to the machine or memory.

… you will note from that statement it has been done. The discussion really should be about how to build similar into the OS.

American

As is a great deal of technology, but I provided that document as that is what the UK’s Information Commissioner’s Office regard as the acceptable standard. I can point you at the guidance if you wish.

Encryption of a filesystem might to something to think about, but forget about the boot password. It’s theatre.

Encryption password…

if the data can be copied onto a USB key

Of course. But if your employees and partners know they can’t do that (and sign a contract for this), you can be GDPR compliant.

Encryption is only here to ensure data will be safe if the computer is physically stolen. No more, no less.

Stop thinking about protecting the operating system and start thinking about protecting the data that it has access to.

You have two solutions here:
1/ protect the system and its data as a whole
2/ ensure every application is GDPR compliant

In fact, you must apply both.

does this mean that it remains unlocked for the rest of the session?

Of course it is. I have no industry PC here that would not lock after 5 minutes of inactivity. The doors are protected with access cards, and people who work on critical activities did sign a paper where they agree to close their doors each time they leave their working room. We also audited each client/server app, installed a strong security suite and audited the ERP processes.

Basically we did all that was possible.
And that’s what GDPR ask for.

whether it was intentional or negligence

We agree. If a simple solution can block the breach, not to use it is a negligence.

If the filesystem is unlocked as part of boot and then left in an open state, it’s not that much better than if it had never been locked at all.

If everyone can gain access to a powered system, you’re really very negligent, and not GDPR compliant at all. If it’s really needed to leave the system opened (what for?) you can opt for a smart card locker/unlocker. Leave the room: it’s locked. Or you can also anonymize the data coming on these PC.

GDPR implies a lot of issues and solutions. What I want to say is that encryption can’t be avoid. Ever. A system without global encryption CAN’T be GDPR compliant.

But, of course, it’s just one of the measures to take to be GDPR compliant. I work on a GDPR compliance for a small company for months, and there is really a lot to do.

The discussion really should be about how to build similar into the OS.

Absolutely

Encryption is only here to ensure data will be safe if the computer is physically stolen. No more, no less.

No, encryption is there to ensure the data is safe if it is stolen.

How is not really important, there are many good practices (as you mention) but there’s always a way in, even if brute force (and not necessarily physically).

All of your machines have smart cards and trained staff, right? Now tell me they’re connected via ethernet to a central fileserver… Tell me you have web access. Tell me the guy in the cubicle to your left Google’s the company name because he never bothered to learn the site URL… Tell me you have telecommuting. And endless réunions and ROQs where people present their updates pulling the necessary data off WiFi…

Protect the machines reasonably.
Protect the data absolutely.

No, encryption is there to ensure the data is safe if it is stolen.

I was almost sure to say exactly the same thing :)

Protect the machines reasonably.
Protect the data absolutely.

Protect both.

From elsewhere:

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

Much of the issue here is the legal pedantry that revolves around the means of COULD, SHOULD, MUST

In real people terms these tend to be roughly

1. Having the ability to do
2. Strongly advised to do and if you don’t we may be unhappy
3. Do or else

So, how easily can encryption be added to the data read/write?

Protect both.

Nice to know your company has an unlimited budget.
Elsewhere…….

So, how easily can encryption be added to the data read/write?

I was thinking about this while walking up the lane to collect the bin.

I’m not convinced that full disc encryption is useful. On a system that’s locked down tight, okay. But that isn’t RISC OS.

What might be more useful (and deployable) is an image filing system that deals with encrypted data. Let’s call it CryptFS. Now a program is going to need to be written to specifically support CryptFS because there are other things it will need to do, such as requiring a user to log in, and maintaining a timer to automatically shut down the session after X minutes of inactivity – so some application end support will be required.
The app will provide, in some manner, a key to CryptFS, and will then mount the image. Then, like DOSFS or SparkFS, it can do regular FS ops.
It’ll need some thought, though, as RISC OS provides many vectors and events, so how to keep a secret a secret?

That’s my €0,02.

Nice to know your company has an unlimited budget.

Not my company, and it’s quite easy.

1/ data leak from physical thief: full disk encryption
2/ data leak from employees: contract
3/ data leak from hacking: firewall and security tools
4/ data leak from apps: ask for GDPR compliancy
5/ data leak from processes: difficult, but needed

I probably forget a few points.

I’m not convinced that full disc encryption is useful.

It solves many issues (temp files, critical data in swap or hibernation files, etc.). And let’s be fair: on a PC, it’s very easy to achieve. It could be easy on RISC OS too: a master password at boot and let’s go… just crypt/decrypt every I/O.

And since RISC OS is very fast, multiuser could be added quite easily (a master partition with a shared key and users partitions with private keys). Of course, no possibility to switch from one user to one another. Just to boot under one identity, with no way to see files from the others.

Nota : the master partition would be the root one, with common apps. Only the administrator could connect to it R/W, with a private key. Each user would have its own key, to access its own partition. And in each (encrypted) partition, the public key will be present to access the master partition R/O. That could be quite elegant, even if one should disconnect (shutdown) to permit another one to connect (start).

Let’s continue digressions :)

On some SSD there is an integrated FDE feature. RISC OS could have a tool to fix the password, and ask for the password in early boot, if the disk is locked. Of course, it will work only on computers with SATA, and ROM in ROM or Flash.

A possible update for the SATA driver (with TRIM and partitions support)?

Even if there was full disc (or image FS) encryption available on RISC OS, I suspect that the vast majority of data would be decrypted when read by an application … and placed in memory. How would you stop access to that decrypted data from other malicious applications or modules? Every possible place that data may reside needs to be locked down tight … which is even more complicated.

Encrypting the file system is enough.

an image filing system that deals with encrypted data

Bad idea. You drag something from this program to that program and it goes via <Wimp$Scrap> on your unencrypted hard disk, but you don’t bat an eyelid because You Have An Encrypted Something Or Other. False sense of security.

Encrypt the whole disc and be done with it.

how easily can encryption be added to the data read/write?

Very easily. It’s RISC OS. It’s stopping things interfering with your data that’s hard.

How would you stop access to that decrypted data from other malicious applications or modules?

I refer the honourable gentleman to my previous sentence.

A tangent: Wimp_TransferBlock is an abomination and ought to be reined in. It’s mad that there’s a system call to peek the memory of any other task. It’s insane that it can be used to poke into that memory too.

WindowManager should totally disallow it except for that one window described in the most recent RamTransfer message (i.e. only this inviter, only this invitee, only this memory range). Beyond that, no no no.

(And yes, I use that functionality in Zap all the time. Obviously I don’t mean me. Do as I say, not as I do.)

I say this more from a software reliability point of view than a security one. Because you can’t have security on RISC OS.

Even if there was full disc (or image FS) encryption available on RISC OS, I suspect that the vast majority of data would be decrypted when read by an application … and placed in memory. How would you stop access to that decrypted data from other malicious applications or modules?

You can’t. I said earlier : “encryption is only here to ensure data will be safe if the computer is physically stolen. No more, no less.”