[qubes-users] Re: VM CPU mapping - countermeasurements against covert channels via cpu caches?
Hello Andrew, the idea is, if crypt-methods may help... E.g. can holomorphic encryption be used to do all the crypt-key calculation on encrypted data (instead of the plain-text of the key) - so "nobody" can leak key-bis, also if N VMs work in parallel? Kind Regards -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/091a8c50-a8f5-4dd7-b2b4-ac3af02cbfae%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: VM CPU mapping - countermeasurements against covert channels via cpu caches?
091384'019438'0913284'0918324'09: > Hello Ilpo Järvinen, > > would be it an option, if some "secure CPU" is just encrypt the caches before > it handles over the CPU power to other processes? > > Perhaps in the some near future? > > Kind Regards > Please, go read the literature on cache-based side-channel attacks and all the proposed countermeasures. Isolating VMs to different cores which still share the same last level cache, or encrypting the data in the cache (though it's unclear what you mean by "encrypt[ing] the cache") are not sufficient to prevent leaking secret data. Here's a classic example why: https://dl.packetstormsecurity.net/papers/general/flush-reload.pdf. Andrew -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/52f37313-ce0f-926b-b756-a88bafbd1a7e%40riseup.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: VM CPU mapping - countermeasurements against covert channels via cpu caches?
On Tue, 28 Jun 2016, 12384013418489'14'810'4 wrote: > would be the Intel Skylake Technology SGX a solution, so that the keys > cannot be read from the crypto processes? In these covert attacks, the keys are not "read" but leaked. Those leaks are unlikely to be solved by SGX as it's not the threat it is used to counter (i.e., SGX prevents reading of those DRM keys directly from RAM in plain text form :-)). With SGX, the memory is encrypted so that it cannot be "read", however, the CPU still does calculations of an SGX enclave the same way as without them which creates the opportunity for the very same covert channels to form. Other interesting technology in this domain is ability to somehow control cache allocations that is available at least with Broadwell Xeons. However, I'm not convinced it can fully remove cache-based covert channels either. -- i.
Re: [qubes-users] Re: VM CPU mapping - countermeasurements against covert channels via cpu caches?
Hello, would be the Intel Skylake Technology SGX a solution, so that the keys cannot be read from the crypto processes? https://github.com/01org/linux-sgx Kind Regards -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/e4492fa8-6a87-44bb-ab43-cd1ec495b981%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: VM CPU mapping - countermeasurements against covert channels via cpu caches?
Assume my PC has to CPUs. How I can configure Qubes that all black VMs are running under CPU0 and all other VMs are running under CPU1? That would be cool! Kind Regards -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/3ae68167-1923-453f-a9c0-047029b0304d%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: VM CPU mapping - countermeasurements against covert channels via cpu caches?
Hallo Andrew, real crypto works always with air-gapped machines. PC0 handels all encryptions (PC0 is sheltered) PC1 is the achive The charme of this solution is, that the risk of bit-leaks, of the crypto keys can mitigated. In qubes I could use a dual CPU system. CPU0 handels all encryptions in all CyptoVMs (PC is sheltered) CPU1 is the power-support for all other VMs How I can make sure that all CyptoVMs are powered by the cores of the CPU0 and all others by the CPU1? Kind Regards P.S. Optional would be the (external) "crypto-chip" solution, like a FPGA board. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/0c10b5a5-b010-4206-9d2d-4368b478e0a0%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: VM CPU mapping - countermeasurements against covert channels via cpu caches?
Hallo Andrew, real crypto works always with air-gapped machines. PC0 handels all encryptions PC1 is the achive This setup (if PC0 is sheltered) allows to distribute documents without the risk of bit-leaks, e.g. with side channel attacks, of the crypto keys (game over, if you know it). Q looks quite fine for doing a cleaner crypto setup. Perhaps to reach the goal, if on one cpu-core, the caches cannot be safe (I don't know if some real-time OS features or other stuff can prevent the cache-leakages between cores), it will be possible a Q-System with two CPU-chips and a feature that I can be sure that VM0 is using only core0 and all other VMs the core1. So core0 can do all crypto stuff and core1 all application support. Kind Regards -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/6742872f-bd0c-4c3c-a1da-a6ba6475b3e4%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: VM CPU mapping - countermeasurements against covert channels via cpu caches?
1093284'109438'019438'0914328'0913284'0913: > Hi Andrew, > > could it be that with some real-time OS features, it will possible to splitt > the Cores of an CPU in two clean domains? > > This would lead to a better latency performance for real time communication, > like skype and for some "air-gapped engines" inside Q. > > Kind Regards > I'm confused what you're trying to achieve: static scheduling of some VMs on some cores, or the elimination of caches as potential inter-VM covert channels. Can you explain exactly what your goal is? I have an idea: go read up on the relevant literature (which I am sure exists in substantial volume), reformulate your goal if necessary, and tell us what you learn. Andrew -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/a04e1cd0-b9b6-8446-23d3-3022a782ffcf%40riseup.net. For more options, visit https://groups.google.com/d/optout.
