Thread (91 messages) 91 messages, 11 authors, 2018-12-13

Re: [RFC v2 00/13] Multi-Key Total Memory Encryption API (MKTME)

From: Huang, Kai <hidden>
Date: 2018-12-08 01:33:46
Also in: keyrings, linux-mm

On Fri, 2018-12-07 at 23:45 +0000, Sakkinen, Jarkko wrote:
On Fri, 2018-12-07 at 13:59 -0800, Jarkko Sakkinen wrote:
quoted
On Fri, 2018-12-07 at 14:57 +0300, Kirill A. Shutemov wrote:
quoted
quoted
What is the threat model anyway for AMD and Intel technologies?

For me it looks like that you can read, write and even replay 
encrypted pages both in SME and TME. 
What replay attack are you talking about? MKTME uses AES-XTS with physical
address tweak. So the data is tied to the place in physical address space
and
replacing one encrypted page with another encrypted page from different
address will produce garbage on decryption.
Just trying to understand how this works.

So you use physical address like a nonce/version for the page and
thus prevent replay? Was not aware of this.
The brutal fact is that a physical address is an astronomical stretch
from a random value or increasing counter. Thus, it is fair to say that
MKTME provides only naive measures against replay attacks...

/Jarkko
Currently there's no nonce to protect cache line so TME/MKTME is not able to prevent replay attack
you mentioned. Currently MKTME only involves AES-XTS-128 encryption but nothing else. But like I
said if I understand correctly even SEV doesn't have integrity protection so not able to prevent
reply attack as well.

Thanks,
-Kai
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help