[atlas] integrity checks for the Atlas software?

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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ripe.net/ripe/mail/archives/ripe-atlas/attachments/20160112/5581bee0/attachment.html>