aard

A small form factor, small high density connector. Most interfaces are not populated, as on the regular pis, but just lead out via the connector, so you can decide what you want to expose on your compute module carrier. It has a gbit ethernet chip on board, and a pcie chip - rpi4 also has pcie, but it is hooked up to USB3 there. With the compute module you can decide what you want to do with that.

Actually I can’t think of anything that raspberry pi does that can’t be done better by a less expensive alternative.

That has been true even before the price increase - what still makes me use pis now and then is that just so many people are familiar with them, the standardized form factor with lots of extension modules, and the software support - pretty much any software targeting that kind of use has been tested on pi variants.

I’d nowadays go for using compute modules, though - they’re smaller, and you can get them with flash, eliminating the SD card problem many pis had. You can get carrier boards for the compute modules in the classic pi form factor, so you can have the best of both worlds.

I’m using opensuse tumbleweed a lot - this summer I’ve found an installation not touched for 2 years. Was about to reinstall when I decided to give updating it a try. I needed to manually force in a few packages related to zypper, and make choices for conflicts in a bit over 20 packages - but much to my surprise the rest went smoothly.

Not really doing much docker, but a lot of LXC - everything scripted with ansible. I define basic container metadata in a yaml parsed by a custom inventory plugin - and that is sufficient for deploying a container before doing provisioning in it.

I have a soft spot for AMD for sticking with the FOSS community to an extent and for their affirmative action towards open silicon initialisation with OpenSIL.

I’m quite happy with having proper graphics cards again thanks to AMD working with their open source driver - and also looking forward to OpenSIL. Though there’s still the problem with the PSP in their CPUs.

If you go through my posts, just the other day I was asking if the T440p was the last Thinkpad I could put Coreboot on (the answer is yes)

Did you checkout heads? That’s what I’m using on my x230 - seems to be currently the most sensible choice for portable hardware.

I will be employing Faraday cages and metal shielding liberally around my electronics

Also make sure to shield cables. There’s not much public research into passive RF, but from the few people who looked into that we can say that the situation is bad, and the bad guys probably can do a lot of bad things (most likely both display signals and keystrokes from a USB or PS/2 keyboards can be recovered reasonably well from some distance by just analysing the RF sent by the cables)

Unless we’re talking about undisclosed exploits in Android, removing Google and most other proprietary applications should do the trick

Pretty much all phones sold in a bit over a decade no longer have a separate baseband. With a unified memory architecture you possibly have a remotely exploitable (remember, baseband) access to the OS memory, if you manage to bypass memory restrictions - in which case none of the mitigations in the OS will help you as it’s just not aware of you being there. While this is a pretty complex attack it unfortunately has been proven in a few cases to be possible. I don’t keep very important stuff on my phone - I don’t consider it trustworthy.

Thank you for bringing across the point of spying using an accelerometer (I’m interested in how that would work, could you point me towards what I should look for?)

Seems research about being able to recover a phone password/pin by using the phones accelerometer is shadowing search results - I’m pretty sure I’ve seen a paper about a phones accelerometer being used to reconstruct key strokes of a keyboard on the same table a few years ago - pretty much same idea as recovering the keystrokes via sound.

Also note that things like hard disks contain their own embedded computer, and in some cases contain an accelerometer. They also have DMA access…

This level of paranoia isn’t really compatible with modern hardware, and requires a lot of effort.

You’re pretty much limited to stuff that has open firmware available, and even then you have to hope there are no bugs or backdoors in the hardware.

For the intel world almost everything with open firmware is pretty old - some nowadays unsupported, which means no longer microcode updates. And those microcode updates also are a problem - you can’t mitigate everything in kernel space, so usually you’d want them, but they’d also be an attack vector against you.

And even if you manage to trust the computer itself there are a lot of attack vectors surrounding it. Do you have anything capable of recording audio in the same room as your computer? If yes, not a good idea - it has been proven possible to extract passwords from audio recordings of a keyboard. Does the room have windows? That counts as an audio recording device.

If you got rid of that, do you have some other hardware with sensors? There’s a high chance that a device placed on your desk containing an accelerometer would also be capable of extracting your password.

Take into account that your average police raid will not attempt that - they just don’t have the means for that.

If you have managed to become an important enough target that either specialists get called in, or you’ve managed to become target of three letter agencies or the equivalent in your country you will have been targeted by other attacks to gain access to your data, both software and hardware - and if you have to ask that kind of question here you’re very unlikely to successfully defend against them.

Yes, but: somebody trying to attack your machine that way would cut the power and try to freeze your memory modules. So that mitigation wouldn’t trigger.

If you think you really need to guard against that attack you’d have to look into physical security: At room temperature there’s a pretty short window available for saving the contents. So if you manage to remove access of possibly used cooling agents to the memory modules you already made things quite tricky.

Now if you can make removing the memory modules hard as well, and prevent booting anything but what you want to be booted there’s a decent chance it’ll be impossible to recover memory contents.

If that still isn’t good enough you’d have to look into providing a means of physical destruction of the memory modules triggered by a backup power source inside the case on unexpected power loss.

Ugh, Nextcloud. It is always touted but it is such a pain to set up properly,

The problem is mainly maintenance - they do YOLO style database handling, so you can’t miss any release or you have fun upgrading. Plus you need to kick it after installing to upgrade the databases.

Other services (like SoGO) have proper upgrade scripts, and automatically adjust the database schema from pretty much any version on first start after upgrading.

Unless you have one of the dumbed down Fido or whatever only versions yubikey is just a smartcard with key storage, and multiple different applications for interfacing with the keys - and as everybody (at least everybody sane) uses the same crypto algorithms those can be shared for whatever needs that.

For SSH you’ll have at least two options - if you have a GPG key on that thing just use the auth-key on there (create one if you don’t have that yet) for SSH, if not maybe adding a PIV key is the better option, that should be available via PKCS#11 then. There might be additional options as well, though.

If you want to stick with that “one key” approach - get a hardware token like a Nitrokey or a Yubikey. That should also work with most Android SSH clients.

Enterprise SSDs are certified to retain data without power for 3 months. That’s extremely conservative - but I wouldn’t push it to more than about two years.

Will be interesting how much that’ll cost - but generally it looks like we’re finally approaching a point where you can buy small systems with enough RAM and network bandwidth for cheap enough that it makes sense to create ceph OSDs with just one or two disks attached each.

You do the usual network checks first, check if wireguard packages come in, check latest handshake. Depending on your network setup you might want to set a lower MTU than default, or enable PersistentKeepalive.

If none of that shows something useful you can enable debug logging via debugfs:

echo module wireguard +p > /sys/kernel/debug/dynamic_debug/control

You’ll then have additional messages in dmesg. You can switch it off by doing -p instead.

Nowadays I’d recommend a simple postfix + dovecot setup. If you care about a web-UI and possibly some groupware functions put SOGo on top.

I like how you have a home smartcard. I can’t believe many do.

Pretty much anyone should do. There’s no excuse to at least keep your personal PGP keys in some USB dongle. I personally wouldn’t recommend yubikey for various reasons, but there are a lot more options nowadays. Most of those vendors also now have HSM options which are reasonably priced and scale well enough for small hosting purposes.

I started a long time ago with empty smartcards and a custom card applet - back then it was quite complicated to find empty smartcards as a private customer. By now I’ve also switched to readily available modules.

Why do you think cloud operators are lying?

One of the key concepts of the cloud is that your VMs are not tied to physical hardware. Which in turn means the key storage also isn’t - which means extraction of keys is possible. Now they’ll tell you some nonsense how they utilize cryptography to make it secure - but you can’t beat “key extraction is not possible at all”.

For the other bits I’ve mentioned a few times side channel attacks. Then there’s AMDs encrypted memory (SEV) claiming to fully isolate VMs from each other, with multiple published attacks. And we have AMDs PSP and intels ME, both with multiple published attacks. I think there also was a published attack against the key storage I described above, but I don’t remember the name.

I agree that our stuff is unlikely to be victim of an targeted attack in the cloud - but could be impacted by a targeted attack on something sharing bare metal with you. Or somebody just managed to perfect one of the currently possible attacks to run them larger scale for data collection - in all cases you’re unlikely to be properly informed about the data loss.

The encryption tech in many cloud providers is typically superior to what you run at home to the point I don’t believe it is a common attack vector.

They rely on hardware functionality in Epyc or Xeon CPUs for their stuff - I have the same hardware at home, and don’t use that functionality as it has massive problems. What I do have at home is smartcard based key storage for all my private keys - keys can’t be extracted from there, and the only outside copy is a passphrase encrypted based64 printout on paper in a sealed envelope in a safe place. Cloud operators will tell you they can also do the equivalent - but they’re lying about that.

And the homomorphic encryption thing they’re trying to sell is just stupid.

Overall, hardened containers are more secure vs bare metal as the attack vectors are radically diff.

Assuming you put the same single application on bare metal the attack vectors are pretty much the same - but anybody sensible stopped doing that over a decade ago as hardware became just too powerful to justify that. So I assume nowadays anything hosted at home involves some form of container runtime or virtualization (or if not whoever is running it should reconsider their life choices).

My point is that it is simpler imo to button up a virtual env and that includes a virtual network env

Just like the container thing above, pretty much any deployment nowadays (even just simple low powered systems coming close to the old bare metal days) will contain at least some level of virtual networking. Traditionally we were binding everything to either localhost or world, and then going from there - but nowadays even for a simple setup it’s way more sensible to have only something like a nginx container with a public IP, and all services isolated in separate containers with various host only network bridges.

Well with bare metal yes, but when your architecture is virtual, configuration rises in importance as the first line of defense

You’ll have all the virtualization management functions in a separate, properly secured management VLAN with limited access. So the exposed attack surface (unless you’re selling VM containers) is pretty much the same as on bare metal: Somebody would need to exploit application or OS issues, and then in a second stage break out of the virtualization. This has the potential to cause more damage than small applications on bare metal - and if you don’t have fail over the impact of rebooting the underlying system after applying patches is more severe.

On the other hand, already for many years - and way before container stuff was mature - hardware was too powerful for just running a single application, so it was common to have lots of unrelated stuff there, which is a maintenance nightmare. Just having that split up into lots of containers probably brings more security enhancements than the risk of having to patch your container runtime.

Encryption is interesting, there really is no practical difference between cloud vs self hosted encryption offerings other than an emotional response.

Most of the encryption features advertised for cloud are marketing bullshit.

“Homomorphic encryption” as a concept just screams “side channel attacks” - and indeed as soon as a team properly looked at it they published a side channel paper.

For pretty much all the technologies advertised from both AMD and intel to solve the various problems of trying to make people trust untrustworthy infrastructure with their private keys sidechannel attacks or other vulnerabilities exist.

As soon as you upload a private key into a cloud system you lost control over it, no matter what their marketing department will tell you. Self hosted you can properly secure your keys in audited hardware storage, preventing key extraction.

Regarding security issues, it will depend on the provider but one wonders if those are real or imagined issues?

Just look at the Microsoft certificate issue I’ve mentioned - data was compromised because of that, they tried to deny the claim, and it was only possible to show that the problem exists because some US agencies paid extra for receiving error logs. Microsofts solution to keep you calm? “Just pay extra as well so you can also audit our logs to see if we lose another key”

Listing Microsoft cloud after their recent certificate mess is an interesting choice.

Also, the “cloud responds to vulnerability” only works if you’re paying them to host the services for you - which definitely no longer is self hosting. If you bring up your own services the patching is on you, no matter where they are.

If you care about stuff like “have some stuff encrypted with the keys in a hardware module” own hardware is your only option. If you don’t care about that you still need to be aware that “cloud” or “VPS” still means that you’re sharing hardware with third parties - which comes with potential security issues.

Interesting, I never encountered that - though that also fits the “2.5 decades” timeframe.

It still shows the author of the error message has no idea about networking: even if we assume network classes apply to RfC 1918 addresses (which they don’t) the majority of those addresses are class A or class B networks.

And looking at it the other way round (using “class C” synonymous with "private addresses) doesn’t work - the majority of addresses in class C space are public addresses.