This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/ripe-atlas@ripe.net/
[atlas] integrity checks for the Atlas software?
- Previous message (by thread): [atlas] integrity checks for the Atlas software?
- Next message (by thread): [atlas] integrity checks for the Atlas software?
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Dario Ciccarone
dario.ciccarone at gmail.com
Tue Jan 12 19:46:41 CET 2016
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: </ripe/mail/archives/ripe-atlas/attachments/20160112/5581bee0/attachment.html>
- Previous message (by thread): [atlas] integrity checks for the Atlas software?
- Next message (by thread): [atlas] integrity checks for the Atlas software?
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]