Re: [PATCH v3 1/7] storage: implement network profile encryption

[James Prestwood <prestwoj at gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1872 bytes --]

Hi Joseph,

On Fri, 2022-02-04 at 15:55 -0700, Joseph Benden wrote:
> Hi!
> 
> It is my understanding that all secret data is to be kept as securely
> as 
> possible. I'm not really seeing this carried throughout the source
> code. 
> Maybe this specific code does not need that level of security?

Currently any profile (e.g. /var/lib/iwd/foo.psk) containing secret
data is unencypted, plaintext. We rely on the file system permissions
to 'secure' this data (which this patch series is 'fixing' for anyone
who wants these encrypted).

> 
> If I'm right, then:
> 
> The secret data should be kept in a mmap(), and mlock(), structure.
> The 
> prevents secret data from hitting swap memory. After every use of the
> secret data; it must be explicit_bzero() and then free(). This is so 
> critical and tedious that it should be a macro or something from
> libell. 
> And those are just initial thoughts for the basic safety of the
> secret data.

So this is how the systemd feature works: The IWD service is given a
path to a file. This file is decrypted by systemd and contains the
'secret'. IWD then reads this secret in, does some hashing, and stores
the hashed secret in RAM. Once IWD is done it never accesses the file
again.

So I don't think its even possible for IWD to do this mmap/mlock dance
you're describing. It really doesn't own this secret file, nor does it
keep the file contents around long. It just derives a fixed length key
and never uses the file again.

As far as explicit_bzero'ing the hashed secret after every use, then
reading it back in, and hashing it again when needed... this seems a
bit crazy :)

Thanks,
James

> 
> Best regards,
> -Joe
> _______________________________________________
> iwd mailing list -- iwd(a)lists.01.org
> To unsubscribe send an email to iwd-leave(a)lists.01.org