Hello everyone,
Today I find some time to write up Security Saturday. As I am writing this up I have another busy week behind me, but this time I have been busy with some security project so I will tell you all about it.
For a project I am setting up a Raspberry Pi using Raspbian (Raspberry Pi OS, as some call it now). It will display some aggregate data that is not traceable to individual entries in the original data stream. However, the data behind the aggregation is actually detailed enough that disclosing it falls under GDPR regulation.
Moreover, in order to properly display this data, the Pi will have to get access to some accounts that are set up for this purpose. That is not a problem in itself, but going from no account to admin account (when attacking) is a bigger barrier than going from "restricted pi account" to admin account. this is because privilege escalation might exist on it's own next to any defense you have against malicious account takeover.
The problem arises because having those accounts saved on the pi means that anyone who gets the SD card out will be able to read the secrets in order to give themselves access to part of our password manager and part of our cloud environment.
So the situation is as follows: Raspberry Pi has some secrets in order to process some aggregate data based on some data stream containing personal information that falls under GDPR regulation.
The crux of the matter here is that the Pi should be able to boot up and just display the data. the point here being that automatic password-less login would be a requirement. However, it should also be able to hold at least one secret password through a reboot. Using that one secret password we could use our password manager to automate getting all the other secrets.
The problem here is obviously that if you login automatically, and you have the password to get all passwords laying around on the SD card, then when someone steals it, it's duck season on all the secrets behind that password.
However, when encrypting a folder transparently - so that you can access it while booted, but pulling the SD card will only give you the encrypted data since it is decrypted on the fly in memory - also requires a password. Either that password is the one you enter on login (which would deny the possiblity of passwordless auto-login), or you enter the password later to start decrypting. In the latter case you would need the password somewhere in a script or, again, enter it manually every time a reboot happens.
So we are back to the start, but now we need to hide the decryption key for the encrypted folder instead of hiding the password to our password manager.
As of yet I do not have a solution to this, only the insight that if you solve the problem of hiding the decryption key, you solve the problem of hiding the password manager's password. So you might as well just skip the encryption step.
But Nevy, are there no other options?
Why, I am glad you asked. There is at least one other option. Since we try to defend against attacks where someone just lifts the SD card from the Pi, we could have folder encryption and base the decryption key on environment. For example: combine the Pi's serial number with the present MAC address on the wired interface.
of course, someone knowing your setup script could narrow down the password because both SN and MAC are in known formats with known parts to them. If the attacker has more time, they could actually try to figure out what SNs and MACs would be likely given the type of Raspberry Pi.
Someone more into specific types of security could probably tell you how smarty or dumb this idea is, I give it a solid "If I must..." quality, since it does defend against the most common type of attacker that nabs just the SD card.
As for the whole box being stolen? Well, even a windows box with TPM 2.0 on there would be toast if auto-login is on. So I equate those risks.
A last solution is, of course, to have no secrets on the pi's, but just a website that displays screenshots. Manage that website from within a closet on premises, or have your data handled inside the cloud and connect the Pi's over VPN to a static slideshow site updating these images.
Actually, now that I said that out loud, that sounds like a good idea. Thanks you all for being my rubber duckies :)
I believe @adamstaplesdev talked about programming in pairs before, and behold. I paired myself up against you all to figure out a security issue and together we did it.
Stay safe out there!
There is so much more to this one chapter, but it is so good already!
I had to cut it short because guests arrived, but this should get you started on your own study :)
@calvinrempel Thank you once again for the Theology Tuesday you did, I refer back to it in this one :)
@JamesDerian Congratulations with your Marriage :)
Next time there might (almost certainly) not be a Theology Tuesday, so the official next one will be February 22nd! I have a marriage to attend. As the groom. Our home is still half a project.
Fun times!
Alc and I talk about my book that is now officially finished. This is part 1 of 2. Parts have not been neatly cut. Part two will air 5 minutes after part 1 for coninuity!
Hope you enjoy :)
This is the third corner to have persistent discussions and talks in. I love tech, but especially once it transcends hardware a little. I have two degrees; a bachelor's in Software Engineering and a master's in Information Security Technology. My graduation thesis focused on assembly-level optimizations (that is, one level above the hardware level) and my free subjects were in formal verification. This is why I love programming in the security corner, or maybe it is the other way around.
I started going down the Security path because I early on saw that the world around us would become a dangerous cesspool of badly-implemented and hostile tech. Now I am one of the people that understands the field around that mess :)
So in here you can discuss secure phones, weird programming languages, sad truths about internet-connected fridges. Also about malware, adblockers, and so on and so fort!
A lot of tech talk I do over at the @Lunduke community, where a lot of nerds hang out and it is ...
Much like the reading corner, let's have a music corner! A few rules for this one, since some music can be provocative. I don't mind much but let's keep youtube links with risque thumbnails out of here.
Other music I might also mind. "Do you find that offensive?" might someone ask. Yes, there is some music I choose not to listen on principle, and I walk a thin line there sometimes. But do not worry, I have a wide taste otherwise so feel free to share almost anything :)
Either way, here is the music corner!
Many times when we talk about security, we mean to say "Digital security". In essence we mean to say that our hardware and software that we use stays safe no matter what we do. And even though the ISO27001 standard (and by extension, for example, the NEN7510 standard) make it abundantly clear that security is a people-domain problem, we usually take that as a process-like truth. Meaning, we think that being secure is a matter of regulating people.
The truth is very different. For example, while writing this I am pretty shot. I slept five hours and I an under influence of a bunch of painkillers and some alcohol. Before you ask what I was thinking, let me mention that I have a genetic defect in my spine that I am dealing with right now by taking measured doses of all three (and yes, to get the Bible into this conversation, there is even a biblical ground for the inebriation with alcohol - see proverbs and the letters to Timothy - , although I did not use red wine. But hey, I am still on top of ...
