<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif;"><div>What Micha said :)</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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</div><div><br></div><span id="OLK_SRC_BODY_SECTION"><div style="font-family:Calibri; font-size:11pt; text-align:left; color:black; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM: 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; BORDER-RIGHT: medium none; PADDING-TOP: 3pt"><span style="font-weight:bold">From: </span> ripe-atlas <<a href="mailto:ripe-atlas-bounces@ripe.net">ripe-atlas-bounces@ripe.net</a>> on behalf of Micha Bailey <<a href="mailto:michabailey@gmail.com">michabailey@gmail.com</a>><br><span style="font-weight:bold">Date: </span> Tuesday, January 12, 2016 at 1:16 PM<br><span style="font-weight:bold">To: </span> Tanner Ryan <<a href="mailto:canadatechguy@gmail.com">canadatechguy@gmail.com</a>><br><span style="font-weight:bold">Cc: </span> Wilfried Woeber <<a href="mailto:woeber@cc.univie.ac.at">woeber@cc.univie.ac.at</a>>, "<a href="mailto:ripe-atlas@ripe.net">ripe-atlas@ripe.net</a>" <<a href="mailto:ripe-atlas@ripe.net">ripe-atlas@ripe.net</a>><br><span style="font-weight:bold">Subject: </span> Re: [atlas] integrity checks for the Atlas software?<br></div><div><br></div><blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;">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.<br><br>On Tuesday, January 12, 2016, Tanner Ryan <<a href="mailto:canadatechguy@gmail.com">canadatechguy@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I think that is completely possible.<div><br></div><div>The only issue is that it will take up far more resources validating the integrity of the code (which could be used for measurements).<br><br>On Tuesday, 12 January 2016, Wilfried Woeber <<a href="javascript:_e(%7B%7D,'cvml','woeber@cc.univie.ac.at');" target="_blank">woeber@cc.univie.ac.at</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br> While thinking about options or mechanisms to make virtual probes "tamper-proof"<br> I had this question coming up:<br><br> Is the probe software capable to "verify" (check-sum or digital sig) the bootstrap<br> kit and then, during run-time, verify that the code in memory is still genuine?<br><br> Thanks,<br> Wilfried<br><br><br></blockquote></div></blockquote></blockquote></span></body></html>