I picked up a shitty NUC from ewaste and it had a label on it for an AI company(digipres.club)
digipres.club
I picked up a shitty NUC from ewaste and it had a label on it for an AI company
https://digipres.club/@foone/112990331505043510
74 comments
Every time I hook my dev NUC up to my HDMI cable and plug in a keyboard, just to decrypt the ssd en get back to working after a reboot, I will now be thinking of this story and feel better about this little nuisance. (Yeah I know there are better ways, I could ssh into the boot env with systemd, I could just encrypt the home dir, I could somehow use the TPM (but that is still pita) etc, I'll look at that the next time I set up the a dev machine...)
You can use "keyscript=" in "/etc/crypttab" to run any script you want.
Using that you could set up networking and download the key from somewhere (say a remote KMS that would need user approval before continuing). So you would reduce your problem to being prompted on phone to unlock your desktop.
You could even use some sort of hardware key to prove request came from the physical server. (simplest might be a RP2350 with some key burnt in)
Or you could use something like SGX if it's still available anywhere to prove the same.
Using that you could set up networking and download the key from somewhere (say a remote KMS that would need user approval before continuing). So you would reduce your problem to being prompted on phone to unlock your desktop.
You could even use some sort of hardware key to prove request came from the physical server. (simplest might be a RP2350 with some key burnt in)
Or you could use something like SGX if it's still available anywhere to prove the same.
> You can use "keyscript=" in "/etc/crypttab" to run any script you want.
...unless your distro uses systemd, which removes keyscript support [1] because the systemd guy "really dislikes generic callouts"
[1] https://github.com/systemd/systemd/pull/3007
...unless your distro uses systemd, which removes keyscript support [1] because the systemd guy "really dislikes generic callouts"
[1] https://github.com/systemd/systemd/pull/3007
For years I've used https://github.com/anatol/booster to unlock LUKS partitions using network bound disk encryption with https://github.com/latchset/clevis and https://github.com/latchset/tang. Works well, especially as Tang is stateless (so deployment and high availability is easy) and Booster falls back to password entry if Tang is unavailable.
Thumbs up for clevis/tang, happy user here, too!
Did not hear about booster. Its README claims "Clevis style data binding. The encrypted filesystem can be bound to TPM2 chip or to a network service.". Does it mean that it tries to deliver various bindings independently from clevis pins, even when duplicating their functions?
Did not hear about booster. Its README claims "Clevis style data binding. The encrypted filesystem can be bound to TPM2 chip or to a network service.". Does it mean that it tries to deliver various bindings independently from clevis pins, even when duplicating their functions?
you can apparently provide a Unix socket path in /etc/crypttab now, and it will connect and read the key from the socket. so you can have the same functionality, but you have to get at it a different way:
https://github.com/systemd/systemd/pull/17524
https://github.com/systemd/systemd/pull/17524
It's 2024 and keyscript still works fine on ubuntu
I don't use this param at the moment anywhere to confirm experimentally, but I'm pretty sure it's same on Debian: https://salsa.debian.org/cryptsetup-team/cryptsetup/-/blob/7....
If you are physically present but the device is operating headless, and if using LUKS and GRUB, you can use a hardware token such as YubiKey via USB to unlock the device without needing to see the console.
I do this with a gateway/router on a PC Engines APU2 that has an internal SSD.
Just ensure GRUB includes the requisite USB modules in its core image, or use grub-mkstandalone to include all modules in core.
I do this with a gateway/router on a PC Engines APU2 that has an internal SSD.
Just ensure GRUB includes the requisite USB modules in its core image, or use grub-mkstandalone to include all modules in core.
Please don't do this unless you have a backup yubikey with the same key on it..
The Yubikey setup program specifically tells you not to rely on a single key for anything.
Even with LUKSv1 there are seven key slots. On creation generally the first will be a keyboard-entered pass-phrase, then one might add a key-file, and then add the hardware token as another.
With LUKSv2 the seven slot limit doesn't apply.
For headless GRUB is configured to the serial port for its terminal in/out so a passphrase can be typed.
With LUKSv2 the seven slot limit doesn't apply.
For headless GRUB is configured to the serial port for its terminal in/out so a passphrase can be typed.
Or all state-full data is securely backup up of course.
What are the benefits of encryption here?
If hardware is stolen it will have hardware key attached.
It is similar to having unencrypted ssd.
Also, someone can temporarily remove the yubikey, fetch the decryption key then place it back.
If hardware is stolen it will have hardware key attached.
It is similar to having unencrypted ssd.
Also, someone can temporarily remove the yubikey, fetch the decryption key then place it back.
> hardware key attached
Key is on my keychain. not attached to the box. I don't need to unlock it remotely. I want to be there and plug my key and touch it and yank it.
> Also, someone can temporarily remove the yubikey, fetch the decryption key then place it back.
If implemented correctly. Nobody can. An encrypted LUKS key would be sent to the yubikey and have it decrypted there. Not the other way.
Key is on my keychain. not attached to the box. I don't need to unlock it remotely. I want to be there and plug my key and touch it and yank it.
> Also, someone can temporarily remove the yubikey, fetch the decryption key then place it back.
If implemented correctly. Nobody can. An encrypted LUKS key would be sent to the yubikey and have it decrypted there. Not the other way.
Ah, I missed that use case, nice idea
For unattended reboots with encrypted root disks (reboot while you sleep), use Mandos: <https://www.recompile.se/mandos>
Disclosure: I am a co-author of Mandos.
Disclosure: I am a co-author of Mandos.
YubiKey
I guess insolvency law needs to be changed to place some duty of care towards data subjects on insolvency practitioners, rather than allowing everything to be flogged off to the highest bidder. Since winding up user data storage safely is not free, this probably means data processors[1] should be required to get insolvency insurance to cover it.
[1] "data processor" in the sense of the various user data protection laws, not just any data processor
[1] "data processor" in the sense of the various user data protection laws, not just any data processor
It's hard to explain to my non-technical friends/relatives, i.e., everyone I know outside work, why I'm careful about digital security and privacy.
[deleted]
What the hell is happening that developers still have the hubris to roll their own secrets manager?
Stage 1: "Things are simple, our only secret is this AWS key, we don't need a secret manager."
Stage 2: "For consistency, we'll handle our second and third secrets just like that first secret. Or handle them through our existing configuration management system, with just some minor tweaks."
Stage 3: "If we mess up the credentials for these edge devices, the software update, monitoring and remote management features will break and we'll have to recall the devices. We should be very cautious about making any changes."
Stage 4: "Even with a secret manager, we'd have to protect the credential used to access the secret manager. Not to mention a long-lived credential to bootstrap new devices, or re-image broken devices in the field. The real solution here is Secure Boot and credentials tied into the TPM. If we want to do this, we'll need a team of six full-time developers and our own custom linux distro"
Stage 5: "End-user features and business value are our priority right now, credential rotation is on the schedule for Q3 next year"
Stage 2: "For consistency, we'll handle our second and third secrets just like that first secret. Or handle them through our existing configuration management system, with just some minor tweaks."
Stage 3: "If we mess up the credentials for these edge devices, the software update, monitoring and remote management features will break and we'll have to recall the devices. We should be very cautious about making any changes."
Stage 4: "Even with a secret manager, we'd have to protect the credential used to access the secret manager. Not to mention a long-lived credential to bootstrap new devices, or re-image broken devices in the field. The real solution here is Secure Boot and credentials tied into the TPM. If we want to do this, we'll need a team of six full-time developers and our own custom linux distro"
Stage 5: "End-user features and business value are our priority right now, credential rotation is on the schedule for Q3 next year"
Yet the "architect" arguing to use Kubernetes is the one making things more complicated and only doing it for their resume?
You know what they say. Both can be true.
This is not even a secrets manager problem. Those have their place but it’s a different link in the chain, or I guess layer in the onion.
The answer to this type of thing is full disk encryption (FDE). There’s zero reason not to have it on every device at the block level. Especially if you’re going to be processing highly sensitive data.
You can’t even trust disks to actually delete things anyway. So the only way to be sure that information is not leaked is to prevent it from ever being persisted to disk in plaintext.
The answer to this type of thing is full disk encryption (FDE). There’s zero reason not to have it on every device at the block level. Especially if you’re going to be processing highly sensitive data.
You can’t even trust disks to actually delete things anyway. So the only way to be sure that information is not leaked is to prevent it from ever being persisted to disk in plaintext.
Lack of senior infra engineer-itis. It's fairly normal not to realise there are entire ecosystems of tools and conventions to solve certain problems if you haven't come across them many times before.
I have a question about that, for my personal accounts I have created a simple php file that I store locally where I can input one password that I know. Then it gets hashed with a salt + salt based on the website that I use this password at.
This hash of 24 chars is my password for that account. I don't trust any of the online password managers. Is this actually safe or not?
Note: this is not used for any of my professional work
This hash of 24 chars is my password for that account. I don't trust any of the online password managers. Is this actually safe or not?
Note: this is not used for any of my professional work
“Ah I can just roll my own in half an hour!” Says the person with a learning curve ahead of them!
"We've got $10M VC money and I've always wanted to try writing a secrets manager"
Resümee driven engineering?
Sometimes you feel like implementing one will take shorter than configuring one.
It's a phase we all go through, but some of us are stuck there forever.
It's a phase we all go through, but some of us are stuck there forever.
This is the opposite of that. If they had practiced resumé driven development, that NUC would have been an k8s node that had secrets encrypted at-rest on top of FDE.
Where do I need to hang out so that I can also score stacks of NUCs from a dumpster?
Start bringing good coffee and treats to your local recycling center for the person/people who work there when you recycle stuff. After doing that a couple of times, ask nicely if you can take some hardware people are throwing.
Alternative approach, hang out outside your target location to figure out when/where they throw stuff, and when trash collectors come. Arrive somewhere in between and dumpster dive :)
Alternative approach, hang out outside your target location to figure out when/where they throw stuff, and when trash collectors come. Arrive somewhere in between and dumpster dive :)
Beware that both approaches might be considering stealing in some jurisditions.
How often that is taken into consideration is another matter.
How often that is taken into consideration is another matter.
It’s actually so sad. Last time I was at the recycling center a couple of years ago there was a Nintendo 64 in the electronics waste. I bet that it probably still worked. And even if it didn’t it would have been fixable. But I wasn’t allowed to pick it up.
Instead this console just has to get destroyed. And for what? It’s not even like a Nintendo 64 is going to have any personal data on it that poses any danger to the previous owner.
And on the flip side if the argument is that the electronics could be dangerous because they are broken. I probably run the same risk when buying electronics second hand anyway. So I don’t think that should prevent them from letting people pick up things either.
Instead this console just has to get destroyed. And for what? It’s not even like a Nintendo 64 is going to have any personal data on it that poses any danger to the previous owner.
And on the flip side if the argument is that the electronics could be dangerous because they are broken. I probably run the same risk when buying electronics second hand anyway. So I don’t think that should prevent them from letting people pick up things either.
> Beware that both approaches might be considering stealing in some jurisditions.
Yeah, most definitely, which is why you need to befriend them before asking, otherwise it's a guaranteed "No, we cannot do that".
Yeah, most definitely, which is why you need to befriend them before asking, otherwise it's a guaranteed "No, we cannot do that".
FWIW The fact that stuff is in a open dumpster doesn't make it legal for you to collect it.
As the case is with so many things, the answer is it depends. https://www.findlaw.com/injury/torts-and-personal-injuries/d...
Start a business to recycle old hardware.
I used to be a little bit sad that dumpster diving would be a phenomenon lost to time. Not so, it turns out; I guess everything old is new again, just in slightly altered forms.
Just Google “dumpster diving for food” and how alive and well that is might surprise you.
I was was obviously referring to <http://www.catb.org/jargon/html/D/dumpster-diving.html>.
Security by irrelevance.
On paper, that’s a catastrophe. In practice, however, even criminals won’t extract much value from these random logs and video records.
On paper, that’s a catastrophe. In practice, however, even criminals won’t extract much value from these random logs and video records.
I can come up with some ideas for the voice assistant logs to be useful if the S3 bucket contains a lot of them:
- getting private numbers of known people (from "call Some Name")
- spam targeting from calendar event creation
- various private info available from dictated notes
- getting private numbers of known people (from "call Some Name")
- spam targeting from calendar event creation
- various private info available from dictated notes
Just get any recent database leak for that on any of the numerous sites trading breaches / leaks. Voice samples can be useful for scammers of course, but the victim needs to be rich enough to justify the attack (and it is easy enough to get a voice sample anyway if you have the phone number). Etc.
It's a new source. Of course there's a different way to get that info too. It's like saying "we had one leak, there's no value in any new data leaks ever".
Is there a danger this is from a cloud provider, not the startup, and the provider just dumped old rack parts without sanitizing them?
A cloud provider wouldn't use NUCs. Seriously, they have better things to do with their time than rack and stack multiple tiny boxes with PSUs (and, apparently, external USB fans as well).
Also, serious cloud providers (besides using server-grade hardware) have to follow proper equipment destruction and recycling procedures--Azure datacenters, for instance, used to have an on-site industrial shredder for disks (which were nevertheless hardware encrypted, but any failing storage was destroyed anyway).
Also, serious cloud providers (besides using server-grade hardware) have to follow proper equipment destruction and recycling procedures--Azure datacenters, for instance, used to have an on-site industrial shredder for disks (which were nevertheless hardware encrypted, but any failing storage was destroyed anyway).
It’d be a huge screwup for a major provider. They promise at-rest encryption and secure disposal of media to their enterprise customers so that’d be a very expensive omission.
In this case, there’s no indication of that and it’s so poorly handled that it radiates a startup winging it where they “didn’t have time” to hire anyone with a clue since the AI gold rush was right there. Given the reported healthcare data this seems like an especially bad choice.
In this case, there’s no indication of that and it’s so poorly handled that it radiates a startup winging it where they “didn’t have time” to hire anyone with a clue since the AI gold rush was right there. Given the reported healthcare data this seems like an especially bad choice.
No - because the startup had labelled their kit.
Your data, your responsibility. No matter where you host.
Sure.
A cloud provider can copy your data without you knowing, they might migrate a host from one cluster to another and copy the data along with it and I would find it unreasonable to be held accountable if they forgot to scrub the source.
It would still be my problem at the end of the day.
It would still be my problem at the end of the day.
encrypted at rest means no, but you're welcome to encrypt it another time if you don't believe them.
“Move fast and break things” strikes again.
My work NUC just shuts down if I start any AI process, be that running an LLM or stable diffusion. Pooof, system off. Temperature doesn't matter. It also doesn't boot when I activate all processor cores. I have to leave one of those unused. Although that may be due some "valuable" feature like secure boot or bitlocker.
I heard NUC now goes to ASUS, perhaps the devices can improve. There are quite a few problems here.
I mean I expected abysmal performance on any pure CPU AI task, but some of those could have run in the background. I wonder what Intel did with the time they were the dominant player on a lot of markets...
The security here is just that the device is so bad, that no party could extract something useful. Seriously, these things...
I heard NUC now goes to ASUS, perhaps the devices can improve. There are quite a few problems here.
I mean I expected abysmal performance on any pure CPU AI task, but some of those could have run in the background. I wonder what Intel did with the time they were the dominant player on a lot of markets...
The security here is just that the device is so bad, that no party could extract something useful. Seriously, these things...
I feel justified on hammering the decommissioning process now. Just pull the disk and destroy it...
Yeah, those boxes in the loading docks of data centers... Lots of interesting stuff.
Picked up a SFF Dell desktop from a huge pile of identical ones in a large cardboard box last spring. They had the good sense, however, to harvest the SSD and memory. Got replacements for a song and now I run home assistant on that thing.
There's also sometimes "old iron" in the dock. Sun servers from back in the day. Beautiful hardware but not something one would ever want to take home.
Picked up a SFF Dell desktop from a huge pile of identical ones in a large cardboard box last spring. They had the good sense, however, to harvest the SSD and memory. Got replacements for a song and now I run home assistant on that thing.
There's also sometimes "old iron" in the dock. Sun servers from back in the day. Beautiful hardware but not something one would ever want to take home.
[deleted]
[deleted]
Charity subsidising the broken? US healthcare industry.
So you'd rather we not help someone in need? Because your comment is _very_ insensitive in a personal context.
I don't think it was insensitive, just a fact. Why do I have to read begging messages on a tech forum for a citizen of the world's biggest and richest economy? Maybe that's insensitive to the 4bn other people on the planet living in poverty with no chance of access to healthcare, begging or not.
Also, worth noting that they are currently in need of some help, so consider supporting them: https://digipres.club/@foone/112929955279707608