Article: Intel’s Plans for 3DXP DIMMs Emerge
By: Anne O. Nymous (not.delete@this.real.address), December 12, 2018 2:10 pm
Room: Moderated Discussions
Maynard Handley (name99.delete@this.name99.org) on December 12, 2018 10:26 am wrote:
> Anne O. Nymous (not.delete@this.real.address) on December 12, 2018 12:14 am wrote:
> > Maynard Handley (name99.delete@this.name99.org) on December 11, 2018 4:32 pm wrote:
> > > Anon (no.delete@this.email.com) on December 11, 2018 4:21 pm wrote:
> > > > Maynard Handley (name99.delete@this.name99.org) on December 11, 2018 7:20 am wrote:
> > > > >......
> > > > > The crypto has to be appropriate to the problem. This is NOT the equivalent of network crypto.
> > > > > For example, suppose the equivalent of a random key burned into the device is XOR'd with everything
> > > > > going into and out of an MRAM cache (maybe also XOR-in the relevant addresses).
> > > > > Is that good enough? On the off-chance that someone could extract the contents
> > > > > of the MRAM cache (which may or may not be true?) the assumption is always
> > > > > that they CANNOT extract the contents of these sorts of hardware keys.
> > > >
> > > > Such a scheme would be about as secure as writing a key on a yellow postit on your monitor.
> > >
> > > Why do you say that?
> > > This is not a situation where one can watch a constant stream of data and extract statistics.
> > > My threat model is that someone steals a laptop, delids the chip, and has access to the
> > > frozen contents of the MRAM data. Not even the cache tags, just a collection of lines
> > > of data; and not a constant, changing, stream of data as the CPU executes.
> >
> > Mmmh, but could said attacker not try to log-in for a few times to make sure that known
> > code (from the login routine) resides in the cache (and maybe do a memory snapshot before
> > and after and compare). And then the proposed single static key is 'toast', no?
> >
>
> But now you are assuming a totally different threat model! That's my point.
>
> MY assumption was that we have a laptop that's fully protected by current means (so imagine, eg, an
> Apple laptop with login and flash protected by the T2 and full-disk encryption). We're assuming as
> given that you have no control over the laptop; the ONLY thing that's new is the assumption that you
> can delid the SoC and read out the (uncontrolled, but persistent) contents of the MRAM data.
Sorry in my causal reality that does not "compute" if I can delid the SoC I need to have physical access to the device and should be able to attempt something (like the same action the devices owner would perform to unlock the device) that can lead to predictable data ending up in the cache.
> If your starting point is that you have login control of the laptop, then
> what's new about the MRAM? You have login control, what more do you want!
Well the whole thread model of deliding a SoC is premised on having the damn thing in one's hand and the willingness to destroy the device....
> Anne O. Nymous (not.delete@this.real.address) on December 12, 2018 12:14 am wrote:
> > Maynard Handley (name99.delete@this.name99.org) on December 11, 2018 4:32 pm wrote:
> > > Anon (no.delete@this.email.com) on December 11, 2018 4:21 pm wrote:
> > > > Maynard Handley (name99.delete@this.name99.org) on December 11, 2018 7:20 am wrote:
> > > > >......
> > > > > The crypto has to be appropriate to the problem. This is NOT the equivalent of network crypto.
> > > > > For example, suppose the equivalent of a random key burned into the device is XOR'd with everything
> > > > > going into and out of an MRAM cache (maybe also XOR-in the relevant addresses).
> > > > > Is that good enough? On the off-chance that someone could extract the contents
> > > > > of the MRAM cache (which may or may not be true?) the assumption is always
> > > > > that they CANNOT extract the contents of these sorts of hardware keys.
> > > >
> > > > Such a scheme would be about as secure as writing a key on a yellow postit on your monitor.
> > >
> > > Why do you say that?
> > > This is not a situation where one can watch a constant stream of data and extract statistics.
> > > My threat model is that someone steals a laptop, delids the chip, and has access to the
> > > frozen contents of the MRAM data. Not even the cache tags, just a collection of lines
> > > of data; and not a constant, changing, stream of data as the CPU executes.
> >
> > Mmmh, but could said attacker not try to log-in for a few times to make sure that known
> > code (from the login routine) resides in the cache (and maybe do a memory snapshot before
> > and after and compare). And then the proposed single static key is 'toast', no?
> >
>
> But now you are assuming a totally different threat model! That's my point.
>
> MY assumption was that we have a laptop that's fully protected by current means (so imagine, eg, an
> Apple laptop with login and flash protected by the T2 and full-disk encryption). We're assuming as
> given that you have no control over the laptop; the ONLY thing that's new is the assumption that you
> can delid the SoC and read out the (uncontrolled, but persistent) contents of the MRAM data.
Sorry in my causal reality that does not "compute" if I can delid the SoC I need to have physical access to the device and should be able to attempt something (like the same action the devices owner would perform to unlock the device) that can lead to predictable data ending up in the cache.
> If your starting point is that you have login control of the laptop, then
> what's new about the MRAM? You have login control, what more do you want!
Well the whole thread model of deliding a SoC is premised on having the damn thing in one's hand and the willingness to destroy the device....
Topic | Posted By | Date |
---|---|---|
New article on Intel's 3DXP | David Kanter | 2018/07/23 10:02 AM |
New article on Intel's 3DXP | Groo | 2018/07/23 01:53 PM |
New article on Intel's 3DXP | Michael S | 2018/07/23 02:47 PM |
New article on Intel's 3DXP | Teemo | 2018/07/23 05:38 PM |
New article on Intel's 3DXP | Wes Felterw | 2018/07/23 09:41 PM |
Flash DIMMs = bad idea | David Kanter | 2018/07/24 04:31 AM |
Flash DIMMs = bad idea | Emil Briggs | 2018/07/24 06:30 AM |
Flash DIMMs = bad idea | David Kanter | 2018/07/24 06:49 AM |
Flash DIMMs = bad idea | Michael S | 2018/07/24 06:59 AM |
Flash DIMMs = bad idea | Emil Briggs | 2018/07/24 08:29 AM |
Flash DIMMs = bad idea | Doug S | 2018/07/24 08:49 AM |
price | Michael S | 2018/07/24 03:16 PM |
price | Doug S | 2018/07/24 03:32 PM |
price | Michael S | 2018/07/24 03:49 PM |
Flash DIMMs = bad idea | blaine | 2018/12/03 04:40 PM |
Flash DIMMs = bad idea | Wes Felter | 2018/12/04 12:07 PM |
Flash DIMMs = bad idea | RichardC | 2018/12/04 04:09 PM |
Flash DIMMs = bad idea | Michael S | 2018/07/24 06:51 AM |
Flash DIMMs = bad idea | Adrian | 2018/07/24 07:35 AM |
Flash DIMMs = bad idea | Ricardo B | 2018/07/24 09:24 AM |
Flash DIMMs = bad idea | bakaneko | 2018/07/24 06:55 PM |
New article on Intel's 3DXP | Etienne | 2018/07/25 05:02 AM |
New article on Intel's 3DXP | Howard Chu | 2018/12/01 06:23 AM |
New article on Intel's 3DXP | Michael S | 2018/12/01 08:56 AM |
New article on Intel's 3DXP | anon | 2018/12/01 09:21 AM |
New article on Intel's 3DXP | Howard Chu | 2018/12/01 01:52 PM |
New article on Intel's 3DXP | Adrian` | 2018/12/01 03:43 PM |
New article on Intel's 3DXP | Adrian | 2018/12/01 11:05 PM |
New article on Intel's 3DXP | Howard Chu | 2018/12/11 05:17 AM |
New article on Intel's 3DXP | Adrian | 2018/12/11 05:42 AM |
New article on Intel's 3DXP | Maynard Handley | 2018/12/11 08:20 AM |
New article on Intel's 3DXP | wumpus | 2018/12/11 09:36 AM |
New article on Intel's 3DXP | Anon | 2018/12/11 05:21 PM |
New article on Intel's 3DXP | Maynard Handley | 2018/12/11 05:32 PM |
New article on Intel's 3DXP | Anon | 2018/12/12 12:29 AM |
New article on Intel's 3DXP | Maynard Handley | 2018/12/12 11:32 AM |
New article on Intel's 3DXP | wumpus | 2018/12/12 12:07 PM |
New article on Intel's 3DXP | Maynard Handley | 2018/12/12 12:41 PM |
New article on Intel's 3DXP | Anon | 2018/12/12 03:55 PM |
New article on Intel's 3DXP | Anon | 2018/12/12 03:49 PM |
New article on Intel's 3DXP | Anne O. Nymous | 2018/12/12 01:14 AM |
New article on Intel's 3DXP | anon | 2018/12/12 06:28 AM |
New article on Intel's 3DXP | Maynard Handley | 2018/12/12 11:26 AM |
New article on Intel's 3DXP | Anne O. Nymous | 2018/12/12 02:10 PM |
New article on Intel's 3DXP | innocent bystander | 2018/12/12 10:34 PM |
New article on Intel's 3DXP | anon | 2018/12/12 02:42 PM |
New article on Intel's 3DXP | Howard Chu | 2018/12/02 05:53 AM |
New article on Intel's 3DXP | Adrian | 2018/12/02 07:01 AM |
New article on Intel's 3DXP | Howard Chu | 2018/12/02 11:34 AM |
Intel's 3DXP availability | Etienne Lorrain | 2018/12/03 04:50 PM |