Article: Intel’s Plans for 3DXP DIMMs Emerge
By: Maynard Handley (name99.delete@this.name99.org), December 12, 2018 11:32 am
Room: Moderated Discussions
Anon (No.delete@this.email.com) on December 11, 2018 11:29 pm 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.
> >
> > Is that the threat model you believe you have in mind? If not, well, we are not discussing the same thing.
>
> Unfortunately it makes no difference, a stream versus a static
> corpus does not make a difference to many forms of attack.
>
> >
> >
> > > Unfortunately the fact is that good encryption is hard, and somewhat computationally involved.
> > >
> > > Not to mention the fact that with a static key, both ends
> > > need that key, as as soon as it leaks, its game over.
> >
> > Slogans are great. But the relevance of this one is not especially clear to me.
>
> What do you think is a slogan? That is a simple fact. What part of it doesn't make sense?
> The key is the key.. Abs it must exist at both ends.. If I've of them is insecure
> then the game is over. Too much like a slogan? Sorry but it is simple fact.
I don't know what "both ends need that key" provides in this context.
I'm assuming a fused key that cannot be read by external means and that this key is held in NON-persistent storage (ie a standard register) by the cache controller. I'm not sure how these two facts make the system insecure.
If you're assuming the fused key end can be read, well, then you're assuming away the security in pretty much EVERY piece of hardware on earth.
If you're assuming that the laptop can be snatched away and data read from non-persistent registers, well, then why is MRAM adding any new insecurity --- your magic microscope that can read registers can just read whatever it wants from any part of the laptop you have snatched.
> 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.
> >
> > Is that the threat model you believe you have in mind? If not, well, we are not discussing the same thing.
>
> Unfortunately it makes no difference, a stream versus a static
> corpus does not make a difference to many forms of attack.
>
> >
> >
> > > Unfortunately the fact is that good encryption is hard, and somewhat computationally involved.
> > >
> > > Not to mention the fact that with a static key, both ends
> > > need that key, as as soon as it leaks, its game over.
> >
> > Slogans are great. But the relevance of this one is not especially clear to me.
>
> What do you think is a slogan? That is a simple fact. What part of it doesn't make sense?
> The key is the key.. Abs it must exist at both ends.. If I've of them is insecure
> then the game is over. Too much like a slogan? Sorry but it is simple fact.
I don't know what "both ends need that key" provides in this context.
I'm assuming a fused key that cannot be read by external means and that this key is held in NON-persistent storage (ie a standard register) by the cache controller. I'm not sure how these two facts make the system insecure.
If you're assuming the fused key end can be read, well, then you're assuming away the security in pretty much EVERY piece of hardware on earth.
If you're assuming that the laptop can be snatched away and data read from non-persistent registers, well, then why is MRAM adding any new insecurity --- your magic microscope that can read registers can just read whatever it wants from any part of the laptop you have snatched.
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 |