Assume your devices are compromised
go350.com
go350.com
Short of brain damage, I don't think that would ever happen.
It would be a hassle for my family if I died, though. I'm young, but I should still get that scenario worked out.
It helps pf course, to have account info, but just knowing the place of business is typically enough.
For clarity, living people lose account numbers and access all the time. The death cert. gives you this same power.
Your master password is the key that decrypts your password vault.
Some sort of escrow would be good, that unlocks a document with access instructions upon receipt of a valid death certificate.
I'm sure there are use cases, but it's actually very hard for me to think of them, let alone in just a minute or so.
If I were chucked into a prison and let out after several years with no computer use in between, I would likely forget all my passwords in the meantime. No brain damage needed, just disuse.
Funny you say that. A year ago I went outside to break up a domestic violence situation. I woke up later face down with a brick next to my head. Due to the concussion I forgot my phone's password and that of my ATM card. It took me six months to remember them, although by then I had replaced both.
Shit happens.
I once forgot my phone's unlock pattern. The very same that i had used for years, daily. I'm not someone that normally has memory problems, but i guess a few synapses just refused to do their job for some reason. I actually had an ex tell it to me, otherwise the phone would be bricked (i tried recalling it for basically 2-3 days). Now i have it and the master password for my password database written down and given to a person that i trust.
Kind of a silly and a worrying situation, so it helps to have contingencies for even cases like that. One might worry about Alzheimer's and whatnot after a situation like that, but even healthy "HDDs" occasionally get "bad sectors". Of course, there have also been cases where i forget something that was almost a subconscious memory (e.g. muscle memory) just to remember it a while later.
For context: am in the 20-30 age bracket, no other memory problems or a history of memory problems in my family tree.
Three reasons:
- Banks fubar safe deposit boxes all of the time, in a variety of ways.
- Once the bank figures out that you’re dead, it’s sealed without a court order.
- As you get older it’s more likely that you’ll screw up payments, lose keys or codes, etc.
Also, the attorney will advise your loved ones on what they can do. For example, you need a power of attorney for many things.
https://www.nytimes.com/2019/07/19/business/safe-deposit-box...
Despite the issues, there are still valid uses for a safe deposit box. I live in a highly fire-prone area and keep a backup drive with family photos and documents in a safe deposit box in a local place that won't burn when I do.
https://abc7news.com/archive/8973198/
Note the police are not classifying this as a criminal case (theft), but a civil case.
Which is why you need to put a tamper-proof box INSIDE a security box in a bank. Key to that box will be in your house, far away from bank personnel.
here's a quick blog post I wrote with my plan. The app is trivial to write if you find a library for your preferred language
In that scenario though, I'd also be out of my digital life even if I had access to 1password.
[1]: https://github.com/cyphar/paperback [2]: https://youtu.be/GI9rKdM9rB8
* Further split up the trust such that the key shards can be held by one group but they don't have access to the document (maybe you keep a copy of the document with a lawyer but distribute the keys among your friends and family so that if your lawyer is hacked or bribed they can't reveal the secrets, same goes for if your friends conspire against you).
* Make the shards small, independent of the document size, so that they're always practical for friends to store even if you have a very large document to save.
* You can do a quorum expansion (create new shards that are compatible with the existing shards) without revealing the secret.
There is probably a lot to be said to curate your accounts to assist those sifting through your estate.
The ability to pass your information legacy is important, and complicated. The trope of your mother going through their mother’s papers and finding a long lost love letter - or an unfinished manuscript - is equally plausible today. What secrets lurk in your DMs, Messenger and Signal history? Does your draft blog post actually contain some amazingly insightful observation?
Maybe your family’s memory of you could be enriched with this information? …maybe not?
At the end of (your) day(s), you might take those secrets to your grave, and it’s unlikely that your tombstone will include your GUID, or the Glacier storage URI where your online self will remain until the TOS states otherwise.
REST In Blob
EDIT: RAM-mento Moar-i(sorry, got carried away.. couldn’t help myself :)
Things that need to stay secret. That's why they are secrets. If my passing means that these things are no longer accessible to anyone ever again? Perfect. Works as intended.
I even wrote a trivial console app to let my wife restore my secrets if I were to drop dead tonight.
If I were to be imprisoned, for example, I might want my lawyer and family to be able to access all of my emails from two years ago up to one week ago. If I were to suddenly die, I would want my family to have full access to all of my accounts, with little hassle.
I would like to be able to tell my email provider (through my account settings) that if at least two people out of each of these three groups agree that such-and-such condition has been met, then these people will be granted this sort of access. The process would notify the other members of the groups I defined and have a delay to allow some kind of veto/vote if there is any disagreement. It may be a bit fiddly, but if a standard were defined for how the interaction works from a user's perspective (including steps to make sure you understand the consequences of how you've configured it), at least it could work consistently across all kinds of accounts.
based on their dynamics, I'm feeling pretty good. I know I have some people there that are tech savvy + some that will take good care of their shares and when they should send those to whom.
Implementation is trivial (especially if you find a library) but maybe you can be inspired by my plan https://g3rv4.com/2022/04/a-plan-for-my-secrets
I don't think SecretSharingDotNet has had any audits, and I'm pretty sure i hasn't been checked for side-channel attacks. I couldn't find anything in GitHub [1] saying it's no longer maintained though.
I'm pretty sure a well founded attacker would be able to hack me, but I think it's orders of magnitude more likely that I'll forget my master password, I'll get stolen, my apartment will catch on fire or I'll just die. Those are the scenarios I'm preparing for.
The extra hidden part of the plan is that I try to avoid things that aren't tracable to a trusted human help desk. Anything that involves the words "manage your own private key" is a point of failure that needs a lot of care.
How do you handle your password manager (assuming you use one)?
Assuming what she needs is access to my email (yes) and gigabyte of photos from my drunk college days (no).
Tedious, yes. But fairly reliable and you don't have to place any trust in your attorneys at all, unless they find out who their counterpart is and start working together (very unlikely). If this system wouldn't work for you, you've probably got bigger problems than having to worry about your wife getting into your email after you die.
Personally, my wife would wonder why I'm going to so much trouble to keep my passwords secret from her until I die; but then my personal password store is for services we share like banking, and any passwords she doesn't know are benign things like my email addresses and various website logins that wouldn't matter anyway when I die. Of course I also have my work passwords (I'm the IT manager), but my supervisor and the company owner each have a secured store of all of my work passwords as well, plus the master password to access them, in the event something happens to me (or I'm just on vacation for a week and temporarily unreachable when access is needed).
Much less tedious, and concentrates trust in the one person who should have it - the spouse!
A bit of research might be indicated, before trusting this strategy to perform when needed.
Also, are you going to SSH in every time you need to access a document from your phone? Again, use-cases differ, but that's not a 1-to-1 alternative to, say, Dropbox.
Your original comment amounted to "you don't need to apply updates if you firewall everything", to which I replied "that's not a replacement for a cloud service". Your subsequent comments then amount to "well you can just poke a hole in your firewall for WireGuard". So which is it, do you need to apply updates (e.g. to WireGuard) or not?
I foresee two potential solutions to this.
1) Run everything in a VM like Qubes (essentially nerfs certain application like 3D acceleration without major R&D)
2) Utilize some container runtime to provide isolation for legacy applications and stub out features such as filesystem calls so they do not to be aware of its existence.
Microsoft tried to produce a crippled application runtime for Windows (UWP) with more security, but considering its lack of backwards compatibility and lesser feature-set it is not that surprising that adoption has been an uphill battle.
[0] https://www.thurrott.com/dev/258377/microsoft-officially-dep...
> CCA introduces a new concept of dynamically created “realms”, which can be viewed as secured containerised execution environments that are completely opaque to the OS or hypervisor. The hypervisor would still exist, but be solely responsible for scheduling and resource allocation. The realms instead, would be managed by a new entity called the “realm manager”, which is supposed to be a new piece of code roughly 1/10th the size of a hypervisor.
> Applications within a realm would be able to “attest” a realm manager in order to determine that it can be trusted, which isn’t possible with say a traditional hypervisor. Arm didn’t go into more depth of what exactly creates this separation between the realms and the non-secure world of the OS and hypervisors, but it did sound like hardware backed address spaces which cannot interact with each other.
Besides allowing for more easily isolated security domains, this allows things like (if properly designed) not needing to wait for kernel improvements to take advantage of more/wider vector registers or other changes that change the amount of processor state to serialize/deserialize when task switching.
The DEC Alpha AXP worked somewhat like this with its PALCode firmware. The Tru64 UNIX (and Linux, *BSD, etc.) and VMS kernels actually were unable to execute the privileged CPU instructions. The OS kernel needed to make upcalls to the PALCode, which then could use privileged instructions and could see model-specific registers, etc. The PALCode version used for Tru64 emulated two protection rings, and the PALCode version used with VMS emulated more (I think 4) rings of protection by just keeping an extra integer around for each task, and using that to determine which tasks could currently make which upcalls. One could (and probably should) extend this ring emulation to a bit vector of per-task revokable capabilities that could be passed to child tasks/processes/threads.
Hopefully we see something like this for RISC-V, using seL4 for the "realm manager". This would probably require an extra userspace driver process running to intermediate realm setup and manipulation, but wouldn't be in the critical path for system calls or other userspace drivers.
We're already running hypervisors so many places that it makes sense to run a formally verified separation kernel everywhere, and run hypervisors and OS kernels as userspace daemons. This avoids the hypervisor needing to emulate hardware as an ad-hoc upcall mechanism and instead simplifies both the hypervisor and the OS kernel. The overhead of modern microkernels is so low that your cell phone's baseband processor is likely running an L4 microkernel. It's called paravirtualization when the OS kernel is modified to use upcalls to the hypervisor instead of trying to perform privileged operations that will be trapped (and then emulated) by the hypervisor. Paravirtualization improves VM performance and potentially sidesteps hypervisor emulation bugs, but it would simplify the kernel (and potentially make it easier to optimize) if OS kernels ran paravirtualized even when there is one guest OS per physical computerp
Edit: Of course, there's a small performance hit in the single guest OS case, but if that's the common code path, presumably both hardware and the kernels could be better optimized. Also, if you're supporting OS-opaque realms, you're already paying this hypervisor cost all the time anyway.
Now, if Linux or OpenBSD released support for that hardware, you might be able to trust it.
Maybe per-customer isolation, or per-usecase isolation.
Isolating customer work (or use case like "production deployment") into separate UNIX user accounts works fairly reasonably.
PWAs are the initial movement in that direction. As browser APIs expand and support more use-cases through WebAssembly, WebGPU, native filesystem APIs, etc. more and more apps that were primarily or only available as native can be supported in the browser.
I know that many people hate web apps because they're often slow, clunky, bloated, etc. but a lot of that is changing as the frontend ecosystem embraces new and more efficient frameworks and technologies. The browser provides everything one needs to build fast and responsive applications - It's an issue with incentives and culture more than anything to do with the fundamental tech.
But then again, modern native apps are dog slow on old hardware; Visual Studio 2022 would hang for over 10 seconds at a time, but it's arguably excusable since it doesn't support running on Windows 7 which I was doing.
Edit: I guess that meshes with the article title; assume other people's servers are compromised too.
Even hypervisors routinely have security issues. How often does qubes sandbox get broken by a zero day?
Last time the hardware virtualization (which Qubes uses) was broken was in 2006, and it was done by the Qubes founder: https://en.wikipedia.org/wiki/Blue_Pill_(software).
See also: https://www.qubes-os.org/security/xsa/.
This version of Chrome is a bit old (v93) but it is built with pledge().
I am running it on an older Core 2 Quad Q9550 where I have been able to completely remove the Intel ME malware (I posted the wiped bios elsewhere).
I hope that this is enough.
On Linux I'm sure some AppArmor or flatpak whatever will be the norm one day, once all the kinks are worked out... but for now it seems to work surprisingly well to just not install stuff that isn't popular and trusted.
And by “manually approving all file access” you mean “opening the file in the file picker like normal”, right? There are some apps where using a file picker at all is awkward, but I’d argue in most applications it’s basically what you’d do anyway. Certainly most applications that non-developers would use.
The bigger problem is that lots of Flatpak applications still don’t use portals.
Of course you won't have that layer of isolation if something becomes compromised, but it should make it harder for malicious code to persist on your system without you knowing.
I've been thinking about doing this on my laptop at work. With a bit of thought, it shouldn't be too hard to run for example software compilation or in fact most CLI/TUI tools using a minimal disk and network namespace using systemd or a container runtime.
Practically, this would allow me to put e.g. ever beloved NPM into a disk namespace where a ~/.ssh or even the .git of the repo it is in just doesn't exist and a network namespace in which the company VPN doesn't exist (or it just has a route for the NPM repository host). This can also be used to label the process using SELinux or apparmor as a second line of defense against and possibly after an escape of something bad.
However, time hasn't been available for this so far. And no, it wouldn't be end-user-friendly.
Secure isn't a binary state, it's a spectrum.
At the same time, what is my risk model? Are my NSFW activities THAT interesting? What about my personal notes that contain health details?
I keep an inventory of stuff in my home. Is that ok to keep in Dropbox? Sure the government can access it.. but even if a remote attacker does, is that useful to them?
And of course, as things get more secure they become less accessible. My "very secure" documents archive almost never gets updated.. cuz it's a pain to update it. My daily notes are just chucked in dropbox and get updated all day long...
What the buyers can actually do with a million dropbox contents I'm not sure. But it's obviously better not to let that happen.
Best defense is the same as securing your home: Don't be the easy target on your block. Even just the bare minimum on all your sites (2FA, good password system, anti-virus on your computer) will stop you from being low hanging fruit.
I'd also love to hear anyone knowledgeable in this area to chime in!
With VMs or setting up different profiles?
I record a lot of videos and wrote a little script[0] to help backup and restore my shell history to avoid auto-complete and CTRL + r searches from showing sensitive info (client work, etc.) while recording. I only use one browser for recording which has its own history too.
For my use case that's enough separation, for others it might not be. For example I still need to be careful about running commands like `docker image ls` on video because it has potential to show client work. I just remember to black out sensitive info during editing if it happens to come up.
[0]: https://github.com/nickjj/dotfiles/blob/0076e508403c9981e393...
>Cuddy: "How is it that you always assume you're right?
>House: "I don't, I just find it hard to operate on the opposite assumption."
If you're on a personal desktop at home you've got to place some level of trust in it.
Same with local LAN.
Once you get to more sophisticated server microservices then you can start thinking of the various components as mutually untrusted (until proven otherwise)
Why? I agree that you have to trust something in order to function, but I would think you could distrust the LAN pretty easily at least for certain levels of internal service. That is, it might be a struggle to distrust the LAN if you need, say, NFS or HTTP without internal domain name (to get certs), or maybe some games? But if all you need is internet access you could fully block internal connections, if you need some access you can probably rely purely on SSH, and failing all else you could run wireguard or such and force everything over that.
This is a misunderstanding of the threat in two ways.
First, malware is not purely, or even primarily, a targeted threat. It's actually a shockingly easy attack to scale, and by far the most victims are not any kind of high profile target. They are either unsophisticated or careless computer users, who installed something they shouldn't have. And the thing is, from most malware authors' perspective it doesn't matter that much whom they compromise. All victims can be monetised to some extent, and there is an elaborate ecosystem to make sure that monetisation happens in practice, not just in theory.
Second, the list of high value targets is definitely not limited to criminals and cryptocurrency owners. They might be the only people for whom the risk model is specifically the theft of a key file from the local disk.
But you know what else is a file on the local disk? The browser cookie jar, full of bearer tokens granting access to all your online services. Have a short Instagram name? An established but not particularly popular YouTube channel? Do your banking online? Have an account on Steam with some bought games? All of that is worth money to an attacker, and them realising that value will hurt you.
As for what to do about it? Hardware crypto is the technical answer, but it will take ages to move the ecosystem there. Until then, segregate the things whose compromise would be really harmful to separate devices from the day to day, ideally ones that are actively supported and have a good security model (e.g an iPad or Chromebook).
The main reason to do this isn't that the airgapped computer isn't compromised, but that even if it is, I could monitor all data moving in and out of it.
Even a USB drive passed back and forth could secretly transfer data I don't know about. Secret data is so small compared to the size of modern storage that data could easily hide in too many places.
Is that system a little paranoid? Maybe, but I haven't fully trusted any computer since heartbleed.
This is an interesting problem, and I hope that I'm somehow able to trust again.
Proximity seems to be key to most of these attacks, so maybe physically excluding any possible eavesdroppers, and adding noise sources would create a shell equivalent to guarding that piece of paper.
I also anticipate gathering old/very limited electronics that can be visually inspected or don't have extra capacity to run malicious code to allow auditing the mechanisms of computation.
Thus any USB used to transfer data/software to the air-gapped machine should be destroyed immediately afterwards and you should probably use something like pen & paper as your only allowed output method.
Stainless steel and stamp/engraver
I can imagine bootstrapping a system with trusted hardware (assuming you could get it) by typing in a bootloader + SHA implementation by hand, then using a narrow hardware interface to copy a trustworthy, audited operating system kernel (assuming that also existed) from some other host. The bootloader could check the SHA of that, and then bootstrap the system.
I still think air-gapping works it's just that you need a pretty large airgap. Turn on the shower, fire up the microwave, move around, and hit some incorrect keys with lots of deleting when entering passwords.
You do realize that viruses existed before networks right? Your "method used daily in industry" can very easily carry an unwanted payload.
I'm trying to explore the intersection of high security and utility.
[M]y biggest takeaway was that all of this was quite complicated and did not really have anything to do with what I bought this system for. So I decided to throw in the towel and flip SecureBoot off.
(See last section here, on trust): https://cameronnemo.gitlab.io/posts/lagomorpha/
The hypervisor itself will need to be well protected and you do not want that accessible from your client or the VMs and containers - use a seperate NIC or VLAN. This is the reason why you want a seperate server - the only things the client will see are the shared containers. Let's assume here that VMs and containers are secure - if they aren't, you can replicate this with seperate physical machines.
On the server you can set firewall rules to control access between the different containers. Network storage etc. can also be setup for the containers that need it, with different permissions depending on the situation.
Depending on the stuff you are running, you may want to go the VDI or SSH route. Also there are other options like XPRA, etc. depending on your requirements. The more segmentation you do (i.e. one VM for the dev envionment for a specific app, another for chat and email, etc.), your security will increase at the cost of usability.
I personally do this in a limited fashion (I have secure workstations and VDIs for handling of private/financial information), but do not go the full route of seperating everything out for day-to-day computing.
People, before you go nuts securing your computers routers and phones, talk to your doctors office about adding additional security to your medical records and freeze or add fraud alerts to your credit reports including NCTUE which I had never heard of until someone walked into Verizon and walked out with 4 unlocked iPhones after opening a new account in my name.
It should be possible, for someone who wants a very low chance of losing all their data, to remember 2 or 3 passphrases and compartmentalize access to servers and backups such that most backups are pull instead of push (or have restricted permission ala 'zfs allow') and compromising everything requires attacking multiple platforms all at once.
Make sure it's possible to access everything starting from fresh installs on fresh hardware; once it's clear that one device has been compromised it's best policy to begin fresh on all devices as soon as possible and then start restoring from backups. Have some offline backups.
To be fair, convenience trumps some of these guidelines. Security is hard and only organizations can achieve a high level of resilience since brain backups don't exist yet.
Are there good tools for anomaly/intrusion detection on Linux? Even something as simple as comparing current resource usage with a baseline record of disk/network/CPU utilization.
And an equivalent for phones, too.
Or to stop putting so much trust in them, go back to "using them for communication with other people directly," and assume they're being evil, because if they're not at the OS level, than some app on them is.
I know they're convenient, I've had a smartphone for years, and have in the past 6 months or so gone back to a flip phone, in which the most interesting thing on it is a halfway complete contacts list and some regularly pruned text message threads (regularly pruned because whatever KaiOS uses for a SMS database gets slow if you don't od that).
Is Suricata a good option for network intrusion detection?
The main advantage over a classic "filter firewall" is that it's able to work at the app level.
Forbidding outgoing HTTPS traffic is going to be painful if you regularly use a browser. But that doesn't mean random_local_only.app should be able to reach anything on the internet.
One could filter much of the crapology somewhere safe, and then have a relatively tidy local browsing experience.
I'm too busy to take this idea past the handwaving stage, but it seems like someone should have already done the homework.
Indeed. https://www.mightyapp.com/
For trusted sites (ones the user logged into), this could be disabled.
https://megous.com/dl/tmp/8eaa15e187fa9a2e.png (ff1 being the user)
I trust it more than browser's internal isolation solutions, like tab containers, which I like to use for other things, like testing web apps using different login sessions at once.
I'd hate a remote solution. ;) Though this is not for privacy but more for protection and better low effort isolation.
Does drag and drop work between windows owned by different users?
It doesn't seem like it would do much against a device compromise.
If you come to the conclusion that a device is compromised, the device should be wiped clean, if possible, or binned if not.
Obviously there's sometimes you have to break that rule, but I find it takes a lot of stress out of privacy issues for me.
I mean, yeah? I agree, I guess? But also, that’s not an interesting observation, is it?
I blame complexity btw. Burn it all down and we might be able to start over in rather acceptable digital stone age.