Temp file space: Use RAM, or talk to host storage over Virtio.
Timezone data etc: You would have to fetch that over the network, or from a metadata API such as the one Firecracker provides to VM guests.
2,639 karma · joined June 16, 2012
Obsessed with building more trustworthy systems.
Timezone data etc: You would have to fetch that over the network, or from a metadata API such as the one Firecracker provides to VM guests.
To be fair, there is a kernel - the Go runtime. But since there is no privilege separation it classifies as a unikernel. Performance gains should be expected compared to a system where you have to copy data to/from guest VM kernel space to guest VM user space.
> I wonder if it could run on cloud VMs?
Yes. TamaGo currently runs in KVM guests with the following VMMs: Cloud Hypervisor, Firecracker microvm, QEMU microvm.
> How tiny could the image become?
Roughly the same size as your current Go binary. TamaGo doesn't add much.
I'm pretty sure our official position is that it doesn't apply, rather than it may apply. Note that the article on our website that I quoted is more recent than the one you quoted. I can't find a more recent legal opinion than that.
Regarding backdooring websites, that's interesting. I'll have to ask someone about that. Thanks.
> the outcome from it (backdoors, compromises, coercion etc) will be kept a state secret
I am not a legal expert, but I'm pretty sure you're wrong. The first-order outcome would be a court case that says the law applies to VPNs, or not. The second-order outcome would be secret coercion in a specific criminal case, or nothing. The first-order outcome would be public. Interesting question though. I'll have to ask about this too.
> Much needed (:
Yes. :)
It might interest you to know that I've spent the past six years working on things like that. My role at Mullvad since several years is only strategic, as I spend almost all of my time on applied research. See glasklarteknik.se and tillitis.se.
> (which no amount of software mitigations would thwart, I don't think)
Physical security is hard. However, I see no reason to limit ourselves to only software-based mitigations.
In any case, to my knowledge the law in question doesn't apply to us. If the Swedish government tried to argue otherwise we'd get our lawyers involved.
Having said all of this, I am concerned about National Security Letters and similar concepts. Technologies like reproducible builds, transparency logs, and remote attestation can help there.
https://mullvad.net/en/help/swedish-covert-surveillance-data...
In short, "Mullvad is thus not covered by either the data storage provisions in the LEK for operations subject to a reporting obligation, or the duty to cooperate pursuant to the Covert Surveillance of Data Act."
Yes. On the other hand, it does complicate things for the attacker, whether it is internal (the orgs) or external - a 3rd party attacker would have to compromise both orgs instead of one.
> After all, the two parties are already cooperating to an extent, so why can't they cooperate even more, either voluntarily or at the command of some hostile government?
Voluntarily: If you look at the business incentives that wouldn't make a lot of sense.
Forced by government: Here I'd say look at the jurisdictions of the orgs.
(disclosure: I'm one of the founders of Mullvad)
It's more nuanced than that. Tor's design states the following:
"A global passive adversary is the most commonly assumed threat when analyzing theoretical anonymity designs. But like all practical low-latency systems, Tor does not protect against such a strong adversary."
https://svn-archive.torproject.org/svn/projects/design-paper...
There are tons of ways to de-anonymize users, Tor and VPN users alike. Same goes for mixnets. Whether or not an attacker can acquire a user's real-world identity depends on a lot of parameters. The number of network proxy hops is just one parameter.
Having said that, everything else equal, more hops is better than fewer. Then again, if all the user does is log into Facebook with their real-world identity, the number of hops doesn't matter at all. Or it does, because their adversary isn't Facebook, but their local ISP! It depends on what the user wants to protect against. There is a reason the Tor Project went on to build the Tor Browser. They realized that the sort of anonymity that users were looking for wasn't to be had with only the Tor network. They needed to complement the tor client with privacy protections on the application layer.
Regarding network proxy hops there's also this perspective: strong anonymity, low bandwidth overhead, low latency - choose two. This anonymity trilemma teaches us yet again that security and performance / UX is often at odds. If you want security you have to be prepared for inconvenience.
> FPGA configuration (NVCM). The only secret is UDS, 256 random bits that are baked into FPGA configuration stream, and they are protected by FPGA's read-out protection.
Correct. Here are some more interesting details:
- we're using the Lattice iCE40 UltraPlus FPGA, which is supported by open tooling and has been for a long time. During the course of the project we also had the configuration and locking protocol reverse engineered so that one can configure and lock the FPGA with open tooling.
- the iCE40's Non-Volatile Configuration Memory (NVCM) uses anti-fuse technology for storing the configuration bits, where the 0s and 1s are stored in vias on the die. The physics of how these vias are modified to represent a 0 or a 1 make it very hard to read out information using X-ray, unlike on-die storage implemented using "horizontal" e-fuses. That's the gist of it.
- the FPGA's boot state machine is unfortunately designed such that you can get it to boot an external bitstream from SPI even after you've configured and locked NVCM, and the state of EBRs (block memory) is retained across warm reboots of the FPGA. We took several steps to mitigate this limitation, which, now that I think about it, would make several interesting blog posts. The UDS memory itself is in LCs, you can mix in key material from the host, the exact timing of that is randomized, RAM (implemented in EBR) is has both address and data randomization... and a few more things.
- physical security is hard, and the TKey won't be able to stand up against any and all physical attacks, but I don't think there is any security hardware in the world that is as open and inspectable as the TKey.
There's also Glasklar Teknik AB and Karlstad Internet Privacy Lab AB.
Glasklar does:
- Sigsum, a transparency log design
- System Transparency, a security architecture for transparent systems
- Hosts and maintains the Debian Snapshot service, an archive of the past decade of released Debian packages
KIPL does traffic analysis defense against AI-based classifiers, which Mullvad recently integrated into the VPN app.
Ease into it. We have fairly good documentation and some getting started material you can read (tillitis.se, dev.tillitis.se, GitHub) to gauge your level of understanding. The design is also meant to have the bare minimum complexity necessary to accomplish its functionality. It seems to have potential as a learning platform for college students who want to understand computers from the gates and up.
As to why, essentially, one of our cultural tenets is to minimize the amount of customer data we hold, and the amount of time we hold it for.
As for building a decentralized append-only log, that would complicate the design and the threat model quite a bit. In particular it would make proofs of inclusion and consistency much less efficient.
glasklarteknik.se
system-transparency.org
sigsum.org
tillitis.se
This presentation explains the idea and lists similar projects.
https://en.m.wikipedia.org/wiki/Management_of_attention_defi...
Wikipedia is a good start, if you are open to the idea of being proven wrong. There is in fact quite a bit of evidence suggesting that many children with ADHD benefit from getting medicated with e.g. methylphenidate and amphetamine.
Of course ADHD medications come with risks, but the question is if they are on the whole beneficial for the patient or not. Brain surgery has risks, Ibuprofen has risks, exercise has risks.
My understanding of available evidence is that an ADHD diagnosis isn't helpful for everyone. This is partly due to societal stigma and lack of understanding of what ADHD is.
I can highly recommend Russell Barkley as a source of scientific information on the subject.
> He has always had problems concentrating at school, for instance he is good at math but would often misread the problems and answer the wrong question. Do you have advice for him to be able to go through his teenage years?
Know yourself. Cognitive function and executive function are different. Executive function impairment can be contextual. With time secondary and tertiary symptoms might develop depending on how well he treats his condition.
State of the art ADHD treatment is multimodal, i.e. you treat it many different complementary ways. Depending on severity medication is a very important part of it.
Bunnie's work is inspiring, but he is not alone.
As far as verifiable hardware goes, I would argue that Tillitis TKey is more open source than the Precursor. However, they are very different products, and Precursor is a lot more complex and capable. The only reason TKey is more open than Precursor is because TKey is able to use a completely open source FPGA flow, whereas Precursor cannot.
What are your favorite books on software design, functional programming, and/or computing generally? What are your favorite papers on the topic of complexity (as FP defines it)?
I agree with you that the separation of Church and state is a foundational idea of software design and even computing generally. I find it quite beautiful how it manifests in hardware as the two categories of digital logic - combinatorial and sequential. And if we zoom in on the logical expression of memory we see it again - a latch is simply two feedback loops and some combinational logic.
For what it's worth I thought the book was brilliant. Its ideas weren't all obvious to me before I read it. It also inspired me to read Parnas, Wirth, Hoare, and study the Go runtime and compiler.
What should be obvious is this: the fact that the ideas were obvious to you doesn't mean they are obvious to everyone.
Secondly, complexity has many meanings. Managing complexity is incredibly important in the realm of security. I've been dabbling in security for 25 years, but I would certainly not claim to have a deep understanding of functional programming. Nevertheless I understand complexity quite well. I think that's what bothered me the most about your original comment - the idea that people without a background in FP are unqualified to talk about complexity.
If the book had been titled "Formal methods for software design" the lack of algorithms for reducing complexity would have been surprising. As it is about philosophy it should not be surprising that it focuses on heuristics.
One of the projects I'm working on however intends to enable just that. See system-transparency.org for more. There's also glasklarteknik.se.
I realise now that you were probably responding to "This _does_ increase the trust that the VMs are safe from other attackers".
davidczech has already explained it quite well, but I'll try explaining it a different way.
Consider the verification of a signed software update. The verifier, e.g. apt-get, rpm, macOS Update, Microsoft Update or whatever OS you're running. They all have some trust policy that contains a public key. The verifier only trusts software signed by the public key.
Now imagine a verifier with a trust policy that mandates that all signed software must also be discoverable in a transparency log. Such a trust policy would need to include:
- a pubkey trusted to make the claim "I am your trusted software publisher and this software is authentic", i.e. it is from Debian / Apple / Microsoft or whomever is the software publisher.
- a pubkey trusted to make the claim "I am your trusted transparency log and this software, or rather the publisher's signature, has been included in my log and is therefore discoverable"
The verifier would therefore require the following in order to trust a software update:
- the software (and its hash) - a signature over the software's hash, done by the software publisher's key - an inclusion proof from the transparency log
There is another layer that could be added called witness cosigning, which reduces the amount of trust you need to place in the transparency log. For more on that see my other comments in this thread.
> simply asserts that a particular key was generated inside a CPU ... There's currently no good way to prove this step
Yes, but there are better and worse ways to do it. Here's how I think about it. I know you know some of this but I'll write it out for other HN readers as well.
Let's start with the supply chain for an SoC's master key. A master key that only uses entropy from an on-die PUF is vulnerable to mistakes and attacks on the chip design as well as the process technology. A master key memory on-die which is provisioned by the fab, or during packaging, or by the eventual buyer of the SoC, is vulnerable to mistakes and attack during that provisioning step.
I think state-of-the-art would be something like:
- an on-die key memory, where the storage is in the vias, using antifuse technology that prevents readout of the bits using x-ray,
- provisioned using multiple entropy source controlled by different supply chains such as (1) an on-die PUF, (2) an on-die TRNG, (3) an off-die TRNG controlled by the eventual buyer,
- provisioned by the eventual buyer and not earlier
As for the cryptographic remote attestation claim itself, such as a TPM Quote, that doesn't have to be only one signature.
As for detectability, discoverability and deterrence, transparency logs makes targeted attacks discoverable. By tlogging all relevant cryptographic claims, including claims related to inventory and provisioning of master keys, an attacker would have to circumvent quite a lot of safeguards to remain undetected.
Finally, if we assume that the attacker is actually at Apple - management, a team, a disgruntled employee, saboteurs employed by competitors - what this type of architecture does is it forces the attacker to make explicit claims that are more easily falsifiable than without such an architecture. And multiple people need to conspire in order for an attack to succeed.
Interesting. Please elaborate.
Here's how I see it.
Reproducible builds: I think we'll eventually see Linux distributions like Debian make reproducible builds mandatory by enforcing it in apt-get's trust policy. The trust policy could be expressed as "I will only trust .deb packages where their build hash and source hash are signed by three different build pipelines I trust".
Remote attestation: If you ensure that the server's CPU SoC and the TPM have different supply chains, you could construct a protocol where the supply chain attacker would have to own both supply chains in order to impersonate the server.
Transparency logging: One of the projects I've been working on for the past four years is Sigsum (sigsum.org). It is a transparency log with distributed trust assumptions. Our goal was to figure out the essence of transparency logging technology, identify the most significant design parameters, and for each parameter minimise the attack surface. You'll find the threat model on our website.
Here's a recent presentation by my colleague Rasmus on the subject: https://www.youtube.com/watch?v=Mp23yQxYm2c
Here's a recent presentation by me on the subject of system transparency / runtime transparency / the technology underlying Apple PCC: https://www.youtube.com/watch?v=Lo0gxBWwwQE