Hello, All!
What is the best way to do in a case when the driver should store in memory
some security information (crypto keys, for ex)?
My assumptions:
Eugene.
Eugene,
Hello, All!
What is the best way to do in a case when the driver should
store in memory
some security information (crypto keys, for ex)?
My assumptions:
- Disable hibernate.
- Clear that security information during power down, after
power up request
it.
My vote goes for #2.
Maybe I’m not understanding the question properly. Let’s say I connect to
the system with WinDBG, can I see the keys then (assuming I knew what to
look for, obviously)?
Is it that much worse that they are stored in a file on the disk than they
are in memory before hibernation?
Anything that is stored in main memory (or inside a chip that can be
accessed via PCI-bus) can be accessed via a kernel device driver, if the
person writing the code knows what he’s doing. On the other hand, any fool
can use a hex-editor (or some other tools) to examine a hibernation file,
but it’s still not trivial to find a particular type of information unless
you know exactly what you’re looking for.
Also, if you’re trying to clear the information, make sure that you’re
clearing the stack-space too, just in case you have a copy somewhere on the
stack (call a function that fills a large on-stack array usually does the
trick. Just make sure it’s not TOO large so you blow the stack in kernel
mode up…)
This obviously depends a lot on exactly what the purpose of the security
is…
–
Mats
Eugene.
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256You are currently subscribed to ntdev as: xxxxx@3dlabs.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
Greetings mortal, xxxxx@3Dlabs.com!
You wrote on Fri, 27 Feb 2004 11:46:24 -0000:
> What is the best way to do in a case when the driver should store in
>> memory some security information (crypto keys, for ex)?
>> My assumptions:
>> 1. Disable hibernate.
>> 2. Clear that security information during power down, after power up
>> request it.
MP> My vote goes for #2.
MP> Maybe I’m not understanding the question properly. Let’s say I
MP> connect to the system with WinDBG, can I see the keys then (assuming
MP> I knew what to look for, obviously)?
If you have access to the system with debugger that system is not
guarded/configured properly.
MP> Is it that much worse that they are stored in a file on the disk
MP> than they are in memory before hibernation?
In sistuation I mentioned above I mean only one security risk - a security
information is stored on disk. Any disk (magnetic) have a remanent field
therefore storing security information on it “as is” is not secure
(information can be restored even after its deleting and rewriting).
MP> Anything that is stored in main memory (or inside a chip that can be
MP> accessed via PCI-bus) can be accessed via a kernel device driver, if
MP> the person writing the code knows what he’s doing. On the other
MP> hand, any fool can use a hex-editor (or some other tools) to examine
MP> a hibernation file, but it’s still not trivial to find a particular
MP> type of information unless you know exactly what you’re looking for.
In properly configured system (for security reasons, of course) you can’t
plug any device, load any driver and even start an application that you not
allowed to start.
MP> Also, if you’re trying to clear the information, make sure that
MP> you’re clearing the stack-space too, just in case you have a copy
MP> somewhere on the stack (call a function that fills a large on-stack
MP> array usually does the trick. Just make sure it’s not TOO large so
MP> you blow the stack in kernel mode up…)
Ok. But I don’t use kernel stack for arrays. 12k is not so much…
PS: Sorry for my english.
Eugene.
Yah, I’m also facing a somewhat similar problem :).
After reading Hacking the XBOX, it makes me wonder …
Disabling Hibernate is the easy way, assuming your key is safe as long as
the machine is
powered on and system is responding to all events.
If the whole thing is software base, meaning you dont have any firmware
control, I would think that storing/retrieving might not be very robust. May
be you can have a routine or module that generates it correctly, and tie
that routine with caller-callee contract, so that a security protocol would
only allow to genarate the key ( the key genaration algorthim is under the
2way CHAP BEFORE IT GETS INVOKED.
Leaving key on a disk might not be a good idea, depends on the level of
security you want…
-prokash
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Eugene Lomovsky
Sent: Friday, February 27, 2004 3:33 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Hibernate & Security
Hello, All!
What is the best way to do in a case when the driver should store in memory
some security information (crypto keys, for ex)?
My assumptions:
Eugene.
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@garlic.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
> My assumptions:
- Disable hibernate.
…and forget about the laptop owners as a market.
The laptop owners are often very annoyed by the fact that some “great software”
have disabled hibernate on their machine, especially after they have closed the
cover, assumed the machine has hibernated, and put it to a bag to be damaged by
its own heat dissipation
Forget about this option. Forever.
- Clear that security information during power down, after power up request
Correct way.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
> information is stored on disk. Any disk (magnetic) have a remanent field
therefore storing security information on it “as is” is not secure
(information can be restored even after its deleting and rewriting).
Consider the costs of such an operation. At least it is 100% impossible without
the aid from the hard disk vendor.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
> Disabling Hibernate is the easy way, assuming your key is safe as long as
the machine is
powered on and system is responding to all events.
Once again. Forget about the laptop users in this case.
Microsoft’s Jake Oshins once told the story on this forum of the notebook
physically destroyed by heat due to such software
Never, ever veto hibernate. Catching the power IRP and overwriting the
sensitive information with zeroes seems to be a better way.
On awaken, run as if no key is present, and re-retrieve it from the user input,
or from the network negotiation, or from the hardware dongle, or such.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
“Eugene Lomovsky” wrote in message news:xxxxx@ntdev…
> Greetings mortal, xxxxx@3Dlabs.com!
> You wrote on Fri, 27 Feb 2004 11:46:24 -0000:
>
> MP> Is it that much worse that they are stored in a file on the disk
> MP> than they are in memory before hibernation?
>
> In sistuation I mentioned above I mean only one security risk - a security
> information is stored on disk. Any disk (magnetic) have a remanent field
> therefore storing security information on it “as is” is not secure
> (information can be restored even after its deleting and rewriting).
That used to be a relatively easy operation. It’s not so easy anymore.
With the current track pitch and bit rates, both of which define bit
density, using another head besides the one that originally wrote the data
is problematic. The read & write channels are pretty finely tuned to work
with some pretty small signal amplitudes. It’s theorectically possible to
read the analog signal levels and then subtract the logical ones from them
in order to get the remnants, but it’s practically impractical. That’s one
of the reasons why it’s gotten harder to do data recovery on failed hardware
over time.
Not to mention that the magnetic softening necessary for this technique to
work requires some time, and the contents of the hiberfile aren’t especially
long-lived. However, in the theoretical sense, there is some risk there, so
if your paranoia dictates that you be completely safe, and you assume one or
more scenarios which prevent you from destroying the media, then you
shouldn’t have any secrets on the media.
Phil
–
Philip D. Barila Windows DDK MVP
Seagate Technology, LLC
(720) 684-1842
As if I need to say it: Not speaking for Seagate.
Greetings mortal, Maxim!
You wrote on Sat, 28 Feb 2004 21:38:23 +0300:
> information is stored on disk. Any disk (magnetic) have a remanent
>> field therefore storing security information on it “as is” is not
>> secure (information can be restored even after its deleting and
>> rewriting).
MSS> Consider the costs of such an operation. At least it is 100%
MSS> impossible without the aid from the hard disk vendor.
Of course. When the question is the state or industrial secrets any means
are used. AFAIK special services have necessary means…
Eugene.
> MSS> Consider the costs of such an operation. At least it is 100%
MSS> impossible without the aid from the hard disk vendor.
Of course. When the question is the state or industrial secrets any means
are used. AFAIK special services have necessary means…
Then a slegdehammer can help
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com