tag:blogger.com,1999:blog-24586388.post6975144072797589166..comments2023-11-24T09:52:43.963+01:00Comments on The Invisible Things Lab's blog: Trusted Execution In Untrusted CloudJoanna Rutkowskahttp://www.blogger.com/profile/07657268181166351141noreply@blogger.comBlogger17125tag:blogger.com,1999:blog-24586388.post-29023706940284664232012-01-19T12:37:35.139+01:002012-01-19T12:37:35.139+01:00@Crisis: TCG perhaps? (Although We, the Qubes peop...@Crisis: TCG perhaps? (Although We, the Qubes people, have not been invited there).Joanna Rutkowskahttps://www.blogger.com/profile/07657268181166351141noreply@blogger.comtag:blogger.com,1999:blog-24586388.post-56379948150628020482012-01-19T12:32:01.921+01:002012-01-19T12:32:01.921+01:00All this begs the question: is there, and if not, ...All this begs the question: is there, and if not, why not, a task force of delegates from people like Qubes-development, Intel, AMD and a host of others (e.g. security/antivirus companies, renowned "hackers" or their associations) that get together - like in the IEEE groups of former renown - and draft specs for all this rather than Intel meandering from one concept to another?CrisisMavenhttp://crisismaven.wordpress.comnoreply@blogger.comtag:blogger.com,1999:blog-24586388.post-28115884959087515412012-01-17T00:45:26.717+01:002012-01-17T00:45:26.717+01:00You may not have to go so far to build a DRAM emul...You may not have to go so far to build a DRAM emulator or other advanced (and expensive) stuff. Have you ever considered JTAG as a possible way to tap DRAM? At least some modern Intel CPUs support it and JTAG seems to be pretty powerful:<br /><br />http://www.arium.com/products/3/Intel-JTAG-Debuggers.html<br /><br />http://www.windriver.com/products/JTAG-debugging/Probe-emulator/Alexnoreply@blogger.comtag:blogger.com,1999:blog-24586388.post-68091614059927350172011-12-21T18:30:06.530+01:002011-12-21T18:30:06.530+01:00Hey, Joanna
just want to say thank you for Qubes. ...Hey, Joanna<br />just want to say thank you for Qubes. Its good and secure OS.<br />Keep walking!Brillhttps://www.blogger.com/profile/11625411851063963699noreply@blogger.comtag:blogger.com,1999:blog-24586388.post-19618045978742895122011-12-19T07:20:12.181+01:002011-12-19T07:20:12.181+01:00i think the cloud is your only ally here, ironical...i think the cloud is your only ally here, ironically. in the end, you are having to trust *some* big company and big government behind them ... and we all know they are quite permeable to always sway to some interest or other ... in a global context there is always a large population whose interests are denied by such entities ... so the problem will always remain, on both realpolitik and truly ethical levels: many want access to computing resources but can't trust them.<br /><br />no matter how many tpms, crypto dongles, etc, there is always the chance that the guy who made the device sold you out, or built it using backdoored technology...<br /><br />but if you can split your problem up and send to *many* CPUs, then aggregating the result becomes difficult. *YOU* at last have the advantage.<br /><br />the challenge is the same as with TOR, to ensure that you are sending to enough real disparate CPUs, and not to a large number of captured/emulated nodes.<br /><br />in practice, to trust computations coming to you from unknown (anonymous?) nodes, you need to use redundency, having the same compute block processed by several nodes, and cross-check their results.<br /><br />so having divided your problem into small tasks which individually contain little of interest, and having sent each tasklet to several nodes from a very large pool, you may achieve reasonable security, i would guess similar to the way most people use their email ... many interceptors could scrutinise it, most don't, a few probably do, but most people don't care much, not enough to use PGP which has been around for decades and still looks like it has been as good as can be done to solve that problem.<br /><br />certainly, although the disperse nature of the cloud works in favour of security, you can't expect greater security from it than at your own node, since if that is the weakest point, then you expect it to be attacked, and such attacks by anyone who would have the ability to capture/emulate many cloud nodes or subvert CPU hardware, would easily also capture your specific node, no matter where or who you are, if they knew a good reason.<br /><br />at some point, social engineering usually triumphs before such monumental engineering tasks, but the threat of a technical subversion always weighs heavily enough on one side to push us all subtly, and were it to be ignored, how hard do you think it is for a giant hardware manufacturer to say 'oh dear, another FPU bug!' they push out one generation of flawed CPUs, should be enough to remind everyone not to trust the pie-in-the-sky liberty dream software, then can go back to 'rebuilding trust' with their market.<br /><br />so not much point aiming for perfect security at the expense of alarmingly complex engineering, better to accept that politics (and resource limitation perhaps) will win out before we can achieve that, and rather, aim for the most reliable, and often simplest and most generic answers ... easy for the CPU manufacturer to make a 'flaw' in some hard-to-test, little used part of the security apparatus, but hard for them to push out CPUs that cannot do a mv instruction in reasonable time (i'm not an assembly programmer, but i hope you understand what i'm trying to say!) and harder for them to conceal or explain the defect. :)<br /><br />or have i gone too far the other way now? we probably want a middle path, i found your thought train interesting, and will try to read your work thouroughly.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-24586388.post-55395634231462241992011-12-16T10:45:46.368+01:002011-12-16T10:45:46.368+01:00@Ahmed Masud:
I don't really think that tamper...@Ahmed Masud:<br />I don't really think that tampering the ciphertext and thus the plaintext would be such a big problem, if we had FHE.<br />If I wanted a cloud provider to use my algorithm and the provider computes something else - as you said - I cannot really check whether he really computed what I wanted.<br />Due to FHE, he cannot see the result.<br />Now if a cloud provider had like 10.000 customers and 1 customer would actually check the result and find out that it's not correct, it could become public and ruin the cloud provider. I just don't see the motivation why a cloud provider would want to change something he doesn't know much about and where the intervention could ruin him.<br /><br />Anyway this is all way too hypothetical. ;)Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-24586388.post-25241025676841810172011-12-15T22:15:04.678+01:002011-12-15T22:15:04.678+01:00I also see the wrong formatting in Firefox 8 and A...I also see the wrong formatting in Firefox 8 and Android app, but only some spaces are missing, not all of them. The text is still readable.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-24586388.post-12716300720893715232011-12-15T11:53:22.993+01:002011-12-15T11:53:22.993+01:00There are a lot of man-in-the-middle attack scenar...There are a lot of man-in-the-middle attack scenarios that leave a bitter taste in the mouth, unless the entire communications path and intermediate processors are also verified. Which still leaves the problem of ensuring tampering of clear text. Here you would say FHE so let's just have a trivial look at that:<br /><br />As for <a href="http://en.wikipedia.org/wiki/Homomorphic_encryption#Fully_homomorphic_encryption" rel="nofollow">FHE</a> Let's take the situation where you have a scheme where E(x•y) = E(x) • E(y) for some binary operation and you want the CPU to perform the '•' on cypher-text. <br /><br />Trivially a rogue CPU in the cloud can easily take the E(x•y) and "add" a delta to it: E(x•y) • E(z) where E(z) is attacker's operand.<br /><br />Now comes the question of whether or not it is possible to verify (x•y) without calculating (x•y) well that's equivalent of P=NP problem.<br /><br />Now if you could encode the operation • in some way (which is by no means trivial) the only thing i can think of is some form of quantum solution, where any knowledge of the state of machine that performs E(x•y) while it is calculating it will render it chaotic... (Hmm, possible new research direction :))<br /><br />Any how ... some thoughts.Ahmed Masudhttps://www.blogger.com/profile/11969230434155041891noreply@blogger.comtag:blogger.com,1999:blog-24586388.post-24390260451182564932011-12-15T10:22:48.655+01:002011-12-15T10:22:48.655+01:00Well, the basic idea of fully homomorphic encrypti...Well, the basic idea of fully homomorphic encryption (FHE) is to do the operations you want to do on encrypted data. Then, when you decrypt the result, you will get the result as if you had worked on plaintext data.<br />The algorithms themselves which work on the encrypted data are public though.<br />Back to the cloud provider example: I could decide to run some fancy well-known data mining algorithm on my private data, encrypt it using FHE, send it to the cloud provider, who executes the data mining algorithm on that data. Afterwards I receive the encrypted result and decrypt it on my machine to see the real result. Hence I don't need to trust the cloud provider's CPU. Ok I agree that I must trust it to execute the data mining algorithm correctly, but usually the algorithms are not that important to be kept secretly.<br /><br />Anyway this is probably far away in the future. However current research indicates that it might once be possible. Actually there already exist FHE cryptosystems, but they are highly inefficient so far (Craig Gentry et al).Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-24586388.post-9371782352177011912011-12-15T07:12:19.900+01:002011-12-15T07:12:19.900+01:00The anonymous poster is talking about fully homomo...The anonymous poster is talking about <a href="http://en.wikipedia.org/wiki/Homomorphic_encryption" rel="nofollow">fully homomorphic encryption</a>, which, theoretically, could allow to perform arbitrary computations by manipulating <b>ciphertext</b>, without any knowledge of the plaintext. Some signature produced as a part of computation would certify that computation sequence itself was not tampered with. However, this field is not very advanced yet (as far as I know). Possible vulnerabilities are not well understood, and it's totally impractical with current technology.Alexeynoreply@blogger.comtag:blogger.com,1999:blog-24586388.post-90315633348540208122011-12-15T01:34:03.970+01:002011-12-15T01:34:03.970+01:00There is strain of more recent research (Overshado...There is strain of more recent research (Overshadow, Cloudvisor) that tries to tackle this untrusted intermediary problem. Overshadow takes on the idea of a trusted hypervisor that protects user applications from an untrusted OS in the middle. A more recent, and perhaps more promising variant of this idea is Cloudvisor: It takes the form of a small security VMM that uses nested virtualization to prevent a real VMM from inspecting a particular VM.<br /><br />In many ways, this is just a game of controlling the lowest layer, but they (the Cloudvisor people) make a compelling argument that their VMM only needs a small interface to enforce isolation between an untrusted VMM and the different VM's.mzleehttps://www.blogger.com/profile/00215129130452486017noreply@blogger.comtag:blogger.com,1999:blog-24586388.post-44271399914607014592011-12-14T21:25:18.076+01:002011-12-14T21:25:18.076+01:00@Anonymous: can you elaborate more on how could we...@Anonymous: can you elaborate more on how could we not trust the processor?Joanna Rutkowskahttps://www.blogger.com/profile/07657268181166351141noreply@blogger.comtag:blogger.com,1999:blog-24586388.post-73718464835167044712011-12-14T09:59:56.351+01:002011-12-14T09:59:56.351+01:00Fully homomorphic encryption might once solve the ...Fully homomorphic encryption might once solve the cloud computing issues.<br />With fully homomorphic encryption you wouldn't even need to trust the CPU of the cloud provider.<br />But it's still a matter of research...Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-24586388.post-80928248006559888792011-12-14T09:44:26.490+01:002011-12-14T09:44:26.490+01:00@Shayan:
No, of course I didn't assume proper...@Shayan:<br /><br />No, of course I didn't assume properly applied and checked digital signatures -- those should provide ultimate safety, naturally. However, the Corbet's explanation does _not_ resort to them! And we know why: there are lot of e.g. kernel branches on kernel.org that are never (or very rarely) signed! Yet, this doesn't stop the community there from self-comforting that all is fine. Considering this specific example of git, I think it should really be enforcing digital signature (signed tags) on _every_ commit automatically.<br /><br />Regarding the wrong formatting: hmmm, I don't see that. Sounds strange though, because I used Google Blogger to create the blog... Anybody else see this problem?Joanna Rutkowskahttps://www.blogger.com/profile/07657268181166351141noreply@blogger.comtag:blogger.com,1999:blog-24586388.post-71953520887926917912011-12-14T09:34:41.906+01:002011-12-14T09:34:41.906+01:00Are you considering git's signatures when talk...Are you considering git's signatures when talking about the possible hard-to-discover exploits on kernel.org? (considering the only important thing on that server is the kernel itself). Would you please elaborate on these possible exploits?<br /><br />Also, this post is not showing well in google reader (in firefox and in android app). Some spaces between words are missing.Shayan Pooyahttps://www.blogger.com/profile/02565481950740397131noreply@blogger.comtag:blogger.com,1999:blog-24586388.post-19428462244066084322011-12-13T23:06:20.930+01:002011-12-13T23:06:20.930+01:00@c43ssmas73r: the point of the whole exercise is t...@c43ssmas73r: the point of the whole exercise is that it would not be possible to build such a processor emulator for the adversary, because she would not know the private key that is only in a legitimate processor.Joanna Rutkowskahttps://www.blogger.com/profile/07657268181166351141noreply@blogger.comtag:blogger.com,1999:blog-24586388.post-3432335508496980302011-12-13T23:04:24.103+01:002011-12-13T23:04:24.103+01:00No because
...think of an attacker who replaces t...No because<br /><br />...think of an attacker who replaces the processor dies with some kind of processor emulator – a device that looks like processor to the host, but on the other end allows full inspection/modification of its contents (well, ok, this is still a bit tricky, but doable)...c43ssmas73rnoreply@blogger.com