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-boun...@ripe.net> on behalf of Micha Bailey <michabai...@gmail.com> Date: Tuesday, January 12, 2016 at 1:16 PM To: Tanner Ryan <canadatech...@gmail.com> Cc: Wilfried Woeber <woe...@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 <canadatech...@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 <woe...@cc.univie.ac.at >> <javascript:_e(%7B%7D,'cvml','woe...@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 >>> >>>
