linux-kernel - Re: Back to the future.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <3052.81.207.0.53.1178315528.squirrel@secure.samage.net>
Date:	Fri, 4 May 2007 23:52:08 +0200 (CEST)
From:	"Indan Zupancic" <indan@....nu>
To:	"Pavel Machek" <pavel@....cz>
Cc:	"Oliver Neukum" <oliver@...kum.org>,
	"Pekka Enberg" <penberg@...helsinki.fi>,
	"Nigel Cunningham" <nigel@...el.suspend2.net>,
	"Linus Torvalds" <torvalds@...ux-foundation.org>,
	"LKML" <linux-kernel@...r.kernel.org>
Subject: Re: Back to the future.

On Thu, May 3, 2007 14:06, Pavel Machek wrote:
>> > > The kernel can already do compression and encryption.
>> >
>> > Yes, if we all could agree on _which_ compression and encryption
>>
>> Any of those available in the kernel. Where's the problem?
>
> gzip is too slow for this. lzf works okay. Oh and swsusp wants rsa
> crypto.

Then port lzf to the kernel, or help with the lzo port.

Swsusp might want RSA crypto, but it doesn't really need it. Currently
it only uses it to be able to suspend without asking for a passphrase.

So the current sequence is:

1) Generate RSA keys + ask for a passphrase. (Once)

...

2) Suspend. (Encrypt snapshot with public RSA key).

...

3) Ask for the passphrase.

4) Resume.

RSA is used so that the passphrase can be thrown away between 1 and 2.

But the same functionality can be achieved by doing:

1) Define a user password (e.g. /etc/shadow thing). (Once)

2) When a user logs in: get random data and encrypt it with the password,
this becomes the AES key. Store both the data and key in a secure way in
memory, e.g. using the existing kernel key infrastructure.

...

3) Suspend.
   (Encrypt snapshot with the AES key and store the random data.)

...

3) Ask for the passphrase.
   (To get the AES key, encrypt the stored random data.)

4) Resume.

Variants are possible of course, but this is the main idea.

This is secure because the key infrastructure is secure, and even if
it isn't the system must be compromised to get the suspend key before
the suspend is done. But at that point the attacker already has all
information that can be found in the suspend image, and could have done
all kind of things to inflict damage (like installing a key logger).

Advantage of this scheme is that it only need AES and can be done (mostly)
in kernel space. It's also faster and simpler than the current RSA scheme.
Disadvantage is that it wastes at least 32 bytes of memory when the system
is running, to store the data and key.

Only thing that needs to be done in userspace is setting the random data
and AES key, but there exist a suitable interface for that (the key system).
As user login is already done in user space, this can be integrated with
that in a nice way.

Greetings,

Indan

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/