On 11/08/2010 03:12 PM, Gregory Maxwell wrote:
Here is the attack: Your system is running with nice secure encrypted
drives, no console access (or a locked screen on a laptop). The
attacker inserts a bootable USB key and hits the power switch. System
reboots into the USB key, it retrieves
I am not a kernel developer, but I do think it would be a step forward
simply to erase a [substantial|critical] part of the physical memory
before the system enters stages S4 or S5. An option in ACPI driver,
implemented somewhere in acpi_os_stall() ?, I really don't know.
Vaclav M.
--
devel
On 11/11/2010 07:55 PM, Roman Rakus wrote:
On 11/08/2010 03:12 PM, Gregory Maxwell wrote:
Here is the attack: Your system is running with nice secure encrypted
drives, no console access (or a locked screen on a laptop). The
attacker inserts a bootable USB key and hits the power
On 11/08/2010 10:18 AM, Petr Pisar wrote:
So, after quick reading, this is not what I expected. This is just
another kernel block cypher used by dmcrypt to (de)crypt block device
data guartneeing encryption key does no leave CPU by storing the key in
SSE register. The drawback is nobody can
It would be usefull to overwrite some parts of memory (keys etc.),
before the computer is switched off. So, my question is: Is there
already implemented and used some kind of protection?
Boot Memory test from install media (DVD, LiveCD, LiveUSB, etc.)
and let it run for a minute.
Or,
On 2010-11-06, Vaclav Mocek little@email.cz wrote:
It would be usefull to overwrite some parts of memory (keys etc.),
before the computer is switched off. So, my question is: Is there
already implemented and used some kind of protection?
There was a patch for Linux to scramble memory
On 2010-11-06, Vaclav Mocek little@email.cz wrote:
I work like an Embedded SW/HW Developer and my experience is that data
could remain in the dynamic memory for quite long time, even in the room
temperature. I have used it successfully for debugging, when a booting
routine after the
On 2010-11-08, Petr Pisar ppi...@redhat.com wrote:
One of the problem is where to store the key. I found a thesis
http://pi1.informatik.uni-mannheim.de/filepool/theses/diplomarbeit-2010-mueller.pdf
right now which describes working implementation using SSE registers as
a permanent (untill power
On Sun, Nov 7, 2010 at 1:57 PM, Stephen John Smoogen smo...@gmail.com wrote:
Ok there are several different cold boot attacks. The one I think
you are talking about is the removing memory from the system and
reading its contents with a special board. The kernel does not
[snip]
Not even with a
Hi all,
I have read some articles about the Cold Boot Attacks and I am
wondering whether my Fedora box is protected against such kinds of
attack, at least to some extent.
I work like an Embedded SW/HW Developer and my experience is that data
could remain in the dynamic memory for quite long
On 10-11-06 07:36 PM, Vaclav Mocek wrote:
Hi all,
I have read some articles about the Cold Boot Attacks and I am
wondering whether my Fedora box is protected against such kinds of
attack, at least to some extent.
I work like an Embedded SW/HW Developer and my experience is that data
On Sun, 07 Nov 2010 00:36:58 +0100, Vaclav Mocek wrote:
I have read some articles about the Cold Boot Attacks and I am
wondering whether my Fedora box is protected against such kinds of
attack, at least to some extent.
If you have physical access to the box there is no security left.
On Sun, Nov 07, 2010 at 18:44:48 +0100,
Jan Kratochvil jan.kratoch...@redhat.com wrote:
On Sun, 07 Nov 2010 00:36:58 +0100, Vaclav Mocek wrote:
I have read some articles about the Cold Boot Attacks and I am
wondering whether my Fedora box is protected against such kinds of
attack, at
On Sat, Nov 6, 2010 at 17:36, Vaclav Mocek little@email.cz wrote:
Hi all,
I have read some articles about the Cold Boot Attacks and I am
wondering whether my Fedora box is protected against such kinds of
attack, at least to some extent.
Ok there are several different cold boot attacks.
14 matches
Mail list logo
