diff for duplicates of <1544232812.28511.39.camel@intel.com> diff --git a/a/1.txt b/N1/1.txt index 2ff74fd..bd47e83 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -1,26 +1,32 @@ -T24gRnJpLCAyMDE4LTEyLTA3IGF0IDIzOjQ1ICswMDAwLCBTYWtraW5lbiwgSmFya2tvIHdyb3Rl -Og0KPiBPbiBGcmksIDIwMTgtMTItMDcgYXQgMTM6NTkgLTA4MDAsIEphcmtrbyBTYWtraW5lbiB3 -cm90ZToNCj4gPiBPbiBGcmksIDIwMTgtMTItMDcgYXQgMTQ6NTcgKzAzMDAsIEtpcmlsbCBBLiBT -aHV0ZW1vdiB3cm90ZToNCj4gPiA+ID4gV2hhdCBpcyB0aGUgdGhyZWF0IG1vZGVsIGFueXdheSBm -b3IgQU1EIGFuZCBJbnRlbCB0ZWNobm9sb2dpZXM/DQo+ID4gPiA+IA0KPiA+ID4gPiBGb3IgbWUg -aXQgbG9va3MgbGlrZSB0aGF0IHlvdSBjYW4gcmVhZCwgd3JpdGUgYW5kIGV2ZW4gcmVwbGF5IA0K -PiA+ID4gPiBlbmNyeXB0ZWQgcGFnZXMgYm90aCBpbiBTTUUgYW5kIFRNRS4gDQo+ID4gPiANCj4g -PiA+IFdoYXQgcmVwbGF5IGF0dGFjayBhcmUgeW91IHRhbGtpbmcgYWJvdXQ/IE1LVE1FIHVzZXMg -QUVTLVhUUyB3aXRoIHBoeXNpY2FsDQo+ID4gPiBhZGRyZXNzIHR3ZWFrLiBTbyB0aGUgZGF0YSBp -cyB0aWVkIHRvIHRoZSBwbGFjZSBpbiBwaHlzaWNhbCBhZGRyZXNzIHNwYWNlDQo+ID4gPiBhbmQN -Cj4gPiA+IHJlcGxhY2luZyBvbmUgZW5jcnlwdGVkIHBhZ2Ugd2l0aCBhbm90aGVyIGVuY3J5cHRl -ZCBwYWdlIGZyb20gZGlmZmVyZW50DQo+ID4gPiBhZGRyZXNzIHdpbGwgcHJvZHVjZSBnYXJiYWdl -IG9uIGRlY3J5cHRpb24uDQo+ID4gDQo+ID4gSnVzdCB0cnlpbmcgdG8gdW5kZXJzdGFuZCBob3cg -dGhpcyB3b3Jrcy4NCj4gPiANCj4gPiBTbyB5b3UgdXNlIHBoeXNpY2FsIGFkZHJlc3MgbGlrZSBh -IG5vbmNlL3ZlcnNpb24gZm9yIHRoZSBwYWdlIGFuZA0KPiA+IHRodXMgcHJldmVudCByZXBsYXk/ -IFdhcyBub3QgYXdhcmUgb2YgdGhpcy4NCj4gDQo+IFRoZSBicnV0YWwgZmFjdCBpcyB0aGF0IGEg -cGh5c2ljYWwgYWRkcmVzcyBpcyBhbiBhc3Ryb25vbWljYWwgc3RyZXRjaA0KPiBmcm9tIGEgcmFu -ZG9tIHZhbHVlIG9yIGluY3JlYXNpbmcgY291bnRlci4gVGh1cywgaXQgaXMgZmFpciB0byBzYXkg -dGhhdA0KPiBNS1RNRSBwcm92aWRlcyBvbmx5IG5haXZlIG1lYXN1cmVzIGFnYWluc3QgcmVwbGF5 -IGF0dGFja3MuLi4NCj4gDQo+IC9KYXJra28NCg0KQ3VycmVudGx5IHRoZXJlJ3Mgbm8gbm9uY2Ug -dG8gcHJvdGVjdCBjYWNoZSBsaW5lIHNvIFRNRS9NS1RNRSBpcyBub3QgYWJsZSB0byBwcmV2ZW50 -IHJlcGxheSBhdHRhY2sNCnlvdSBtZW50aW9uZWQuIEN1cnJlbnRseSBNS1RNRSBvbmx5IGludm9s -dmVzIEFFUy1YVFMtMTI4IGVuY3J5cHRpb24gYnV0IG5vdGhpbmcgZWxzZS4gQnV0IGxpa2UgSQ0K -c2FpZCBpZiBJIHVuZGVyc3RhbmQgY29ycmVjdGx5IGV2ZW4gU0VWIGRvZXNuJ3QgaGF2ZSBpbnRl -Z3JpdHkgcHJvdGVjdGlvbiBzbyBub3QgYWJsZSB0byBwcmV2ZW50DQpyZXBseSBhdHRhY2sgYXMg -d2VsbC4NCg0KVGhhbmtzLA0KLUthaQ= +On Fri, 2018-12-07 at 23:45 +0000, Sakkinen, Jarkko wrote: +> On Fri, 2018-12-07 at 13:59 -0800, Jarkko Sakkinen wrote: +> > On Fri, 2018-12-07 at 14:57 +0300, Kirill A. Shutemov wrote: +> > > > 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 diff --git a/a/content_digest b/N1/content_digest index 8ddcb82..026f36e 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -6,7 +6,7 @@ "ref\019c539f8c6c9b34974e4cb4f268eb64fe7ba4297.camel@intel.com\0" "From\0Huang, Kai <kai.huang@intel.com>\0" "Subject\0Re: [RFC v2 00/13] Multi-Key Total Memory Encryption API (MKTME)\0" - "Date\0Sat, 08 Dec 2018 01:33:39 +0000\0" + "Date\0Sat, 8 Dec 2018 01:33:39 +0000\0" "To\0kirill@shutemov.name <kirill@shutemov.name>" Sakkinen " Jarkko <jarkko.sakkinen@intel.com>\0" @@ -27,36 +27,44 @@ luto@kernel.org <luto@kernel.org> bp@alien8.de <bp@alien8.de> Hansen + Dave <dave.hansen@intel.com> + Schofield Alison <alison.schofield@intel.com> Nakajima " Jun <jun.nakajima@intel.com>\0" "\00:1\0" "b\0" - "T24gRnJpLCAyMDE4LTEyLTA3IGF0IDIzOjQ1ICswMDAwLCBTYWtraW5lbiwgSmFya2tvIHdyb3Rl\n" - "Og0KPiBPbiBGcmksIDIwMTgtMTItMDcgYXQgMTM6NTkgLTA4MDAsIEphcmtrbyBTYWtraW5lbiB3\n" - "cm90ZToNCj4gPiBPbiBGcmksIDIwMTgtMTItMDcgYXQgMTQ6NTcgKzAzMDAsIEtpcmlsbCBBLiBT\n" - "aHV0ZW1vdiB3cm90ZToNCj4gPiA+ID4gV2hhdCBpcyB0aGUgdGhyZWF0IG1vZGVsIGFueXdheSBm\n" - "b3IgQU1EIGFuZCBJbnRlbCB0ZWNobm9sb2dpZXM/DQo+ID4gPiA+IA0KPiA+ID4gPiBGb3IgbWUg\n" - "aXQgbG9va3MgbGlrZSB0aGF0IHlvdSBjYW4gcmVhZCwgd3JpdGUgYW5kIGV2ZW4gcmVwbGF5IA0K\n" - "PiA+ID4gPiBlbmNyeXB0ZWQgcGFnZXMgYm90aCBpbiBTTUUgYW5kIFRNRS4gDQo+ID4gPiANCj4g\n" - "PiA+IFdoYXQgcmVwbGF5IGF0dGFjayBhcmUgeW91IHRhbGtpbmcgYWJvdXQ/IE1LVE1FIHVzZXMg\n" - "QUVTLVhUUyB3aXRoIHBoeXNpY2FsDQo+ID4gPiBhZGRyZXNzIHR3ZWFrLiBTbyB0aGUgZGF0YSBp\n" - "cyB0aWVkIHRvIHRoZSBwbGFjZSBpbiBwaHlzaWNhbCBhZGRyZXNzIHNwYWNlDQo+ID4gPiBhbmQN\n" - "Cj4gPiA+IHJlcGxhY2luZyBvbmUgZW5jcnlwdGVkIHBhZ2Ugd2l0aCBhbm90aGVyIGVuY3J5cHRl\n" - "ZCBwYWdlIGZyb20gZGlmZmVyZW50DQo+ID4gPiBhZGRyZXNzIHdpbGwgcHJvZHVjZSBnYXJiYWdl\n" - "IG9uIGRlY3J5cHRpb24uDQo+ID4gDQo+ID4gSnVzdCB0cnlpbmcgdG8gdW5kZXJzdGFuZCBob3cg\n" - "dGhpcyB3b3Jrcy4NCj4gPiANCj4gPiBTbyB5b3UgdXNlIHBoeXNpY2FsIGFkZHJlc3MgbGlrZSBh\n" - "IG5vbmNlL3ZlcnNpb24gZm9yIHRoZSBwYWdlIGFuZA0KPiA+IHRodXMgcHJldmVudCByZXBsYXk/\n" - "IFdhcyBub3QgYXdhcmUgb2YgdGhpcy4NCj4gDQo+IFRoZSBicnV0YWwgZmFjdCBpcyB0aGF0IGEg\n" - "cGh5c2ljYWwgYWRkcmVzcyBpcyBhbiBhc3Ryb25vbWljYWwgc3RyZXRjaA0KPiBmcm9tIGEgcmFu\n" - "ZG9tIHZhbHVlIG9yIGluY3JlYXNpbmcgY291bnRlci4gVGh1cywgaXQgaXMgZmFpciB0byBzYXkg\n" - "dGhhdA0KPiBNS1RNRSBwcm92aWRlcyBvbmx5IG5haXZlIG1lYXN1cmVzIGFnYWluc3QgcmVwbGF5\n" - "IGF0dGFja3MuLi4NCj4gDQo+IC9KYXJra28NCg0KQ3VycmVudGx5IHRoZXJlJ3Mgbm8gbm9uY2Ug\n" - "dG8gcHJvdGVjdCBjYWNoZSBsaW5lIHNvIFRNRS9NS1RNRSBpcyBub3QgYWJsZSB0byBwcmV2ZW50\n" - "IHJlcGxheSBhdHRhY2sNCnlvdSBtZW50aW9uZWQuIEN1cnJlbnRseSBNS1RNRSBvbmx5IGludm9s\n" - "dmVzIEFFUy1YVFMtMTI4IGVuY3J5cHRpb24gYnV0IG5vdGhpbmcgZWxzZS4gQnV0IGxpa2UgSQ0K\n" - "c2FpZCBpZiBJIHVuZGVyc3RhbmQgY29ycmVjdGx5IGV2ZW4gU0VWIGRvZXNuJ3QgaGF2ZSBpbnRl\n" - "Z3JpdHkgcHJvdGVjdGlvbiBzbyBub3QgYWJsZSB0byBwcmV2ZW50DQpyZXBseSBhdHRhY2sgYXMg\n" - d2VsbC4NCg0KVGhhbmtzLA0KLUthaQ= + "On Fri, 2018-12-07 at 23:45 +0000, Sakkinen, Jarkko wrote:\n" + "> On Fri, 2018-12-07 at 13:59 -0800, Jarkko Sakkinen wrote:\n" + "> > On Fri, 2018-12-07 at 14:57 +0300, Kirill A. Shutemov wrote:\n" + "> > > > What is the threat model anyway for AMD and Intel technologies?\n" + "> > > > \n" + "> > > > For me it looks like that you can read, write and even replay \n" + "> > > > encrypted pages both in SME and TME. \n" + "> > > \n" + "> > > What replay attack are you talking about? MKTME uses AES-XTS with physical\n" + "> > > address tweak. So the data is tied to the place in physical address space\n" + "> > > and\n" + "> > > replacing one encrypted page with another encrypted page from different\n" + "> > > address will produce garbage on decryption.\n" + "> > \n" + "> > Just trying to understand how this works.\n" + "> > \n" + "> > So you use physical address like a nonce/version for the page and\n" + "> > thus prevent replay? Was not aware of this.\n" + "> \n" + "> The brutal fact is that a physical address is an astronomical stretch\n" + "> from a random value or increasing counter. Thus, it is fair to say that\n" + "> MKTME provides only naive measures against replay attacks...\n" + "> \n" + "> /Jarkko\n" + "\n" + "Currently there's no nonce to protect cache line so TME/MKTME is not able to prevent replay attack\n" + "you mentioned. Currently MKTME only involves AES-XTS-128 encryption but nothing else. But like I\n" + "said if I understand correctly even SEV doesn't have integrity protection so not able to prevent\n" + "reply attack as well.\n" + "\n" + "Thanks,\n" + -Kai -148700b358e4ea0e98a5e515d17bfaf0b9d8c731e54cb8acfb82a674ac299eb4 +35fc531b13e79b2ceb04f6f5af6ed720eb8d1f555034a3fac31f61b75e8f0563
diff --git a/a/1.txt b/N2/1.txt index 2ff74fd..bd47e83 100644 --- a/a/1.txt +++ b/N2/1.txt @@ -1,26 +1,32 @@ -T24gRnJpLCAyMDE4LTEyLTA3IGF0IDIzOjQ1ICswMDAwLCBTYWtraW5lbiwgSmFya2tvIHdyb3Rl -Og0KPiBPbiBGcmksIDIwMTgtMTItMDcgYXQgMTM6NTkgLTA4MDAsIEphcmtrbyBTYWtraW5lbiB3 -cm90ZToNCj4gPiBPbiBGcmksIDIwMTgtMTItMDcgYXQgMTQ6NTcgKzAzMDAsIEtpcmlsbCBBLiBT -aHV0ZW1vdiB3cm90ZToNCj4gPiA+ID4gV2hhdCBpcyB0aGUgdGhyZWF0IG1vZGVsIGFueXdheSBm -b3IgQU1EIGFuZCBJbnRlbCB0ZWNobm9sb2dpZXM/DQo+ID4gPiA+IA0KPiA+ID4gPiBGb3IgbWUg -aXQgbG9va3MgbGlrZSB0aGF0IHlvdSBjYW4gcmVhZCwgd3JpdGUgYW5kIGV2ZW4gcmVwbGF5IA0K -PiA+ID4gPiBlbmNyeXB0ZWQgcGFnZXMgYm90aCBpbiBTTUUgYW5kIFRNRS4gDQo+ID4gPiANCj4g -PiA+IFdoYXQgcmVwbGF5IGF0dGFjayBhcmUgeW91IHRhbGtpbmcgYWJvdXQ/IE1LVE1FIHVzZXMg -QUVTLVhUUyB3aXRoIHBoeXNpY2FsDQo+ID4gPiBhZGRyZXNzIHR3ZWFrLiBTbyB0aGUgZGF0YSBp -cyB0aWVkIHRvIHRoZSBwbGFjZSBpbiBwaHlzaWNhbCBhZGRyZXNzIHNwYWNlDQo+ID4gPiBhbmQN -Cj4gPiA+IHJlcGxhY2luZyBvbmUgZW5jcnlwdGVkIHBhZ2Ugd2l0aCBhbm90aGVyIGVuY3J5cHRl -ZCBwYWdlIGZyb20gZGlmZmVyZW50DQo+ID4gPiBhZGRyZXNzIHdpbGwgcHJvZHVjZSBnYXJiYWdl -IG9uIGRlY3J5cHRpb24uDQo+ID4gDQo+ID4gSnVzdCB0cnlpbmcgdG8gdW5kZXJzdGFuZCBob3cg -dGhpcyB3b3Jrcy4NCj4gPiANCj4gPiBTbyB5b3UgdXNlIHBoeXNpY2FsIGFkZHJlc3MgbGlrZSBh -IG5vbmNlL3ZlcnNpb24gZm9yIHRoZSBwYWdlIGFuZA0KPiA+IHRodXMgcHJldmVudCByZXBsYXk/ -IFdhcyBub3QgYXdhcmUgb2YgdGhpcy4NCj4gDQo+IFRoZSBicnV0YWwgZmFjdCBpcyB0aGF0IGEg -cGh5c2ljYWwgYWRkcmVzcyBpcyBhbiBhc3Ryb25vbWljYWwgc3RyZXRjaA0KPiBmcm9tIGEgcmFu -ZG9tIHZhbHVlIG9yIGluY3JlYXNpbmcgY291bnRlci4gVGh1cywgaXQgaXMgZmFpciB0byBzYXkg -dGhhdA0KPiBNS1RNRSBwcm92aWRlcyBvbmx5IG5haXZlIG1lYXN1cmVzIGFnYWluc3QgcmVwbGF5 -IGF0dGFja3MuLi4NCj4gDQo+IC9KYXJra28NCg0KQ3VycmVudGx5IHRoZXJlJ3Mgbm8gbm9uY2Ug -dG8gcHJvdGVjdCBjYWNoZSBsaW5lIHNvIFRNRS9NS1RNRSBpcyBub3QgYWJsZSB0byBwcmV2ZW50 -IHJlcGxheSBhdHRhY2sNCnlvdSBtZW50aW9uZWQuIEN1cnJlbnRseSBNS1RNRSBvbmx5IGludm9s -dmVzIEFFUy1YVFMtMTI4IGVuY3J5cHRpb24gYnV0IG5vdGhpbmcgZWxzZS4gQnV0IGxpa2UgSQ0K -c2FpZCBpZiBJIHVuZGVyc3RhbmQgY29ycmVjdGx5IGV2ZW4gU0VWIGRvZXNuJ3QgaGF2ZSBpbnRl -Z3JpdHkgcHJvdGVjdGlvbiBzbyBub3QgYWJsZSB0byBwcmV2ZW50DQpyZXBseSBhdHRhY2sgYXMg -d2VsbC4NCg0KVGhhbmtzLA0KLUthaQ= +On Fri, 2018-12-07 at 23:45 +0000, Sakkinen, Jarkko wrote: +> On Fri, 2018-12-07 at 13:59 -0800, Jarkko Sakkinen wrote: +> > On Fri, 2018-12-07 at 14:57 +0300, Kirill A. Shutemov wrote: +> > > > 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 diff --git a/a/content_digest b/N2/content_digest index 8ddcb82..8f468bb 100644 --- a/a/content_digest +++ b/N2/content_digest @@ -6,7 +6,7 @@ "ref\019c539f8c6c9b34974e4cb4f268eb64fe7ba4297.camel@intel.com\0" "From\0Huang, Kai <kai.huang@intel.com>\0" "Subject\0Re: [RFC v2 00/13] Multi-Key Total Memory Encryption API (MKTME)\0" - "Date\0Sat, 08 Dec 2018 01:33:39 +0000\0" + "Date\0Sat, 8 Dec 2018 01:33:39 +0000\0" "To\0kirill@shutemov.name <kirill@shutemov.name>" Sakkinen " Jarkko <jarkko.sakkinen@intel.com>\0" @@ -27,36 +27,43 @@ luto@kernel.org <luto@kernel.org> bp@alien8.de <bp@alien8.de> Hansen + Alison <alison.schofield@intel.com> Nakajima " Jun <jun.nakajima@intel.com>\0" "\00:1\0" "b\0" - "T24gRnJpLCAyMDE4LTEyLTA3IGF0IDIzOjQ1ICswMDAwLCBTYWtraW5lbiwgSmFya2tvIHdyb3Rl\n" - "Og0KPiBPbiBGcmksIDIwMTgtMTItMDcgYXQgMTM6NTkgLTA4MDAsIEphcmtrbyBTYWtraW5lbiB3\n" - "cm90ZToNCj4gPiBPbiBGcmksIDIwMTgtMTItMDcgYXQgMTQ6NTcgKzAzMDAsIEtpcmlsbCBBLiBT\n" - "aHV0ZW1vdiB3cm90ZToNCj4gPiA+ID4gV2hhdCBpcyB0aGUgdGhyZWF0IG1vZGVsIGFueXdheSBm\n" - "b3IgQU1EIGFuZCBJbnRlbCB0ZWNobm9sb2dpZXM/DQo+ID4gPiA+IA0KPiA+ID4gPiBGb3IgbWUg\n" - "aXQgbG9va3MgbGlrZSB0aGF0IHlvdSBjYW4gcmVhZCwgd3JpdGUgYW5kIGV2ZW4gcmVwbGF5IA0K\n" - "PiA+ID4gPiBlbmNyeXB0ZWQgcGFnZXMgYm90aCBpbiBTTUUgYW5kIFRNRS4gDQo+ID4gPiANCj4g\n" - "PiA+IFdoYXQgcmVwbGF5IGF0dGFjayBhcmUgeW91IHRhbGtpbmcgYWJvdXQ/IE1LVE1FIHVzZXMg\n" - "QUVTLVhUUyB3aXRoIHBoeXNpY2FsDQo+ID4gPiBhZGRyZXNzIHR3ZWFrLiBTbyB0aGUgZGF0YSBp\n" - "cyB0aWVkIHRvIHRoZSBwbGFjZSBpbiBwaHlzaWNhbCBhZGRyZXNzIHNwYWNlDQo+ID4gPiBhbmQN\n" - "Cj4gPiA+IHJlcGxhY2luZyBvbmUgZW5jcnlwdGVkIHBhZ2Ugd2l0aCBhbm90aGVyIGVuY3J5cHRl\n" - "ZCBwYWdlIGZyb20gZGlmZmVyZW50DQo+ID4gPiBhZGRyZXNzIHdpbGwgcHJvZHVjZSBnYXJiYWdl\n" - "IG9uIGRlY3J5cHRpb24uDQo+ID4gDQo+ID4gSnVzdCB0cnlpbmcgdG8gdW5kZXJzdGFuZCBob3cg\n" - "dGhpcyB3b3Jrcy4NCj4gPiANCj4gPiBTbyB5b3UgdXNlIHBoeXNpY2FsIGFkZHJlc3MgbGlrZSBh\n" - "IG5vbmNlL3ZlcnNpb24gZm9yIHRoZSBwYWdlIGFuZA0KPiA+IHRodXMgcHJldmVudCByZXBsYXk/\n" - "IFdhcyBub3QgYXdhcmUgb2YgdGhpcy4NCj4gDQo+IFRoZSBicnV0YWwgZmFjdCBpcyB0aGF0IGEg\n" - "cGh5c2ljYWwgYWRkcmVzcyBpcyBhbiBhc3Ryb25vbWljYWwgc3RyZXRjaA0KPiBmcm9tIGEgcmFu\n" - "ZG9tIHZhbHVlIG9yIGluY3JlYXNpbmcgY291bnRlci4gVGh1cywgaXQgaXMgZmFpciB0byBzYXkg\n" - "dGhhdA0KPiBNS1RNRSBwcm92aWRlcyBvbmx5IG5haXZlIG1lYXN1cmVzIGFnYWluc3QgcmVwbGF5\n" - "IGF0dGFja3MuLi4NCj4gDQo+IC9KYXJra28NCg0KQ3VycmVudGx5IHRoZXJlJ3Mgbm8gbm9uY2Ug\n" - "dG8gcHJvdGVjdCBjYWNoZSBsaW5lIHNvIFRNRS9NS1RNRSBpcyBub3QgYWJsZSB0byBwcmV2ZW50\n" - "IHJlcGxheSBhdHRhY2sNCnlvdSBtZW50aW9uZWQuIEN1cnJlbnRseSBNS1RNRSBvbmx5IGludm9s\n" - "dmVzIEFFUy1YVFMtMTI4IGVuY3J5cHRpb24gYnV0IG5vdGhpbmcgZWxzZS4gQnV0IGxpa2UgSQ0K\n" - "c2FpZCBpZiBJIHVuZGVyc3RhbmQgY29ycmVjdGx5IGV2ZW4gU0VWIGRvZXNuJ3QgaGF2ZSBpbnRl\n" - "Z3JpdHkgcHJvdGVjdGlvbiBzbyBub3QgYWJsZSB0byBwcmV2ZW50DQpyZXBseSBhdHRhY2sgYXMg\n" - d2VsbC4NCg0KVGhhbmtzLA0KLUthaQ= + "On Fri, 2018-12-07 at 23:45 +0000, Sakkinen, Jarkko wrote:\n" + "> On Fri, 2018-12-07 at 13:59 -0800, Jarkko Sakkinen wrote:\n" + "> > On Fri, 2018-12-07 at 14:57 +0300, Kirill A. Shutemov wrote:\n" + "> > > > What is the threat model anyway for AMD and Intel technologies?\n" + "> > > > \n" + "> > > > For me it looks like that you can read, write and even replay \n" + "> > > > encrypted pages both in SME and TME. \n" + "> > > \n" + "> > > What replay attack are you talking about? MKTME uses AES-XTS with physical\n" + "> > > address tweak. So the data is tied to the place in physical address space\n" + "> > > and\n" + "> > > replacing one encrypted page with another encrypted page from different\n" + "> > > address will produce garbage on decryption.\n" + "> > \n" + "> > Just trying to understand how this works.\n" + "> > \n" + "> > So you use physical address like a nonce/version for the page and\n" + "> > thus prevent replay? Was not aware of this.\n" + "> \n" + "> The brutal fact is that a physical address is an astronomical stretch\n" + "> from a random value or increasing counter. Thus, it is fair to say that\n" + "> MKTME provides only naive measures against replay attacks...\n" + "> \n" + "> /Jarkko\n" + "\n" + "Currently there's no nonce to protect cache line so TME/MKTME is not able to prevent replay attack\n" + "you mentioned. Currently MKTME only involves AES-XTS-128 encryption but nothing else. But like I\n" + "said if I understand correctly even SEV doesn't have integrity protection so not able to prevent\n" + "reply attack as well.\n" + "\n" + "Thanks,\n" + -Kai -148700b358e4ea0e98a5e515d17bfaf0b9d8c731e54cb8acfb82a674ac299eb4 +5930af512ad7dd02936491c2bad700ce26fb836dda9df3005f80b1c692673514
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.