What Micha said :) DISCLAIMER: I work for a vendor, but the following aren¹t in any way, shape or form my current employer views. It¹s my personal opinion, based, however, on many years of doing IRT. Micha is absolutely right unless you start w/ a TPM-kind of hardware support, there¹s no way to have 100% confidence in that ³what I¹m running is what I¹m supposed to be running². Regrettably, getting trusted boot and execution right is expensive in money and time, and hard to get it absolutely right. I honestly don¹t think the Atlas project would be able to continue w/ the existing business model of using cheap, off-the-shelf hardware, and give it away for free and provide a secure boot/trusted execution kind of probe. RIPE just doesn¹t have that kind of money lying around, AFAIK. Of course, it all depends on who your adversary is, and the kind of resources it has available. While a trusted anchor in hardware, hardware TPM, digital signatures and strong crypto/hardware entropy source and RNG would be needed for a full blown solution (plus all the associated build environment, developers, testers, etc) you can achieve a ³not-too-shabby² middle ground a two-step boot process, a first stage loader checking the signature on the main image before loading & launching it. Of course an attacker could come up w/ a modified binary that doesn¹t even perform this check, and just launches whatever . . . Move the first stage loader to a ROM more expensive, better. But again, it¹s about who you¹re up against based on risk/benefit, RIPE ATLAS may (a) do it all, (b) middle ground, (c) nothing at all From: ripe-atlas <ripe-atlas-bounces@ripe.net> on behalf of Micha Bailey <michabailey@gmail.com> Date: Tuesday, January 12, 2016 at 1:16 PM To: Tanner Ryan <canadatechguy@gmail.com> Cc: Wilfried Woeber <woeber@cc.univie.ac.at>, "ripe-atlas@ripe.net" <ripe-atlas@ripe.net> Subject: Re: [atlas] integrity checks for the Atlas software?
No, this isn't possible. Or rather, it's not feasible with currently-existing software. The *only* way to have any kind of remote assurance of specific software running is through remote attestation, meaning that you have trusted hardware (e.g. a TPM) that can sign a statement that the machine m is running a certain trusted BIOS/EFI/whatever, that signs a statement that the computer is running a certain trusted bootloader, and so on, creating a chain of trusted signatures all the way through the OS and hypervisor certifying that a specific VM is running and can't be interfered with. As far as I know that full software stack doesn't exist at this point, and it arguably shouldn't exist/be used in most cases (see Google results for «remote attestation»). Short of that, there's no way to guarantee that certain code is running unmodified. As soon as the user/owner/hacker/rogue datacenter employee is able to modify anything below the VM in the stack without being detected, they can falsify whatever they want (for example, the hypervisor could be programmed such that certain instructions are stored correctly in memory correctly, but when executing the code it's silently swapped out). It may be possible to make this hard, and even hard enough to be considered acceptable for Atlas (though said protection may not even be considered necessary -- what's our threat model here?), but it can't be made impossible for a determined-enough attacker.
On Tuesday, January 12, 2016, Tanner Ryan <canadatechguy@gmail.com> wrote:
I think that is completely possible.
The only issue is that it will take up far more resources validating the integrity of the code (which could be used for measurements).
On Tuesday, 12 January 2016, Wilfried Woeber <woeber@cc.univie.ac.at <javascript:_e(%7B%7D,'cvml','woeber@cc.univie.ac.at');> > wrote:
While thinking about options or mechanisms to make virtual probes "tamper-proof" I had this question coming up:
Is the probe software capable to "verify" (check-sum or digital sig) the bootstrap kit and then, during run-time, verify that the code in memory is still genuine?
Thanks, Wilfried