Am Donnerstag, 24. Mai 2018, 11:27:56 CEST schrieb Rafael J. Wysocki: Hi Rafael, > On Thursday, May 24, 2018 11:11:32 AM CEST Stephan Mueller wrote: > > Am Donnerstag, 24. Mai 2018, 10:33:07 CEST schrieb Rafael J. Wysocki: > > > > Hi Rafael, > > Hi Stephan, > > > > So the problem is that Yu would like to use this for hibernation > > > encryption > > > done entirely in the kernel. > > > > But why do you need to perform PBKDF in kernel space? > > > > If you retain the password information in the kernel, you could retain the > > derived key instead of the passcode. > > > > If, however, you ask for the user password during resume, you need some > > user space component to query that password. The PBKDF can also be > > handled in user space along with the query. > > In principle it is possible to pass a key to the kernel from user > space, but that doesn't guarantee the key to be a really good one. It > depends on a user space component to do the right thing and IMO that is > risky. > > And please note that the information contained in hibernation images may > be extremely sensitive (keys and similar). > > > Or how do you want to handle the passcode? > > The idea is to write a passphrase to the kernel via something like sysfs, > generate a key from it on the fly and store the key. But what is the difference between a passcode and the key derived from it. The derived key should only spread the assumed entropy in the passcode evenly. In addition with its iteration count, it shall ensure that offline brute force attacks of the passcode using stored protected data is made hard. So, I do not see why it is risky to do the PBKDF in user space and then hand the key to the kernel at runtime. It does not really matter if the attacker sees the plaintext key or the passcode. If the attacker can access the kernel/ user communication channel, we have a problem in any case. Or do I miss something here? Ciao Stephan
