[RFC 0/2] Encrypt secrets using systemd provided key

[RFC 0/2] Encrypt secrets using systemd provided key

[James Prestwood]

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

There has been interest in enabling IWD users to store their network
credentials in some encrypted form. Recently systemd added support for
passing secrets/credentials to services only accessible by the service
they are intended. This provides a clean way of obtaining a secret key
which IWD can use to encrypt anything it writes to the FS. In addition
there is no hard dependency on systemd since the credential is provided
as a file (i.e. no Dbus API or linked library etc).

At the moment setting up the IWD service to use this feature will be
left up to the user. But setting this up is very straight forward. I
used docs for systemd-creds (Example 2):

https://www.freedesktop.org/software/systemd/man/systemd-creds.html

The only difference is the --name argument should be iwd-secret.

Note: systemd version 250 is required.

The reason this is being sent as an RFC is because of some open questions
I had and wanted feedback on:

 1. What options specifically do we want encrypted? These patches only
    address Passphrase and PreSharedKey but really any option could be
    encrypted. Obviously we would also want 802.1x secrets, but are there
    other non-obvious options with privacy concerns?

 2. What is the stance on existing provisioning files? Currently these
    changes overwrite any existing files with the new *Encrypted options
    automatically. Is this desirable? or should user have to opt-in their
    existing provisioning files.

 3. Is the secret provided via a file enough? (the secret is still stored
    as plaintext *somewhere*, though systemd limits permissions). Systemd
    supports an IPC mechanism to obtain the secret. Is this more secure?

 4. Should full provisioning file encryption be optional/supported? I felt
    it was best to only encrypt sensitive options like PSK/Passphrase which
    would allow editing of the provisioning file without extra steps of
    decrypting, editing, and encrypting. I think this is above the capability
    or desire of most users.
    
    If, though, a provisioning file is never expected to change or issued by
    a network administrator that does not want it edited I could see full
    file encryption being ok.

James Prestwood (2):
  main: add SystemdEncrypt option, and initialize key
  network: add support for encrypted Passphrase/PSK

 src/iwd.h     |   1 +
 src/main.c    |  64 ++++++++++++++++++
 src/network.c | 183 ++++++++++++++++++++++++++++++++++++++++++++++++--
 3 files changed, 242 insertions(+), 6 deletions(-)

-- 
2.31.1

Re: [RFC 0/2] Encrypt secrets using systemd provided key

[Diederik de Haas]

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

Hi James,

On vrijdag 21 januari 2022 23:30:44 CET James Prestwood wrote:
> > I did/do wonder why my passphrase is stored in plain-text and not in
> > a form which I can get through the wpa_passphrase* utility (I don't know
> > the proper term for it though). Maybe that's what others have been
> > interested in too?
> 
> I was unfamiliar with wpa_passphrase until now, but all that appears to
> be doing is deriving a PSK from the SSID/passphrase, not 'encrypted' by
> any means. In IWD this is "PreSharedKey" in the profile. Ultimately
> (for WPA2) you only need the PSK to connect to a network so storing the
> PSK directly is just as insecure as the passphrase.

I followed https://wiki.debian.org/WiFi/HowToUse#WPA-PSK_and_WPA2-PSK and then 
removed the commented out line (thus the plain-text passphrase)
I _think_ it was way more prominent and recommended on that page when I first 
read it, quite some years ago.

I knew it wasn't (actually) encrypted, but assumed it to be a (one-way) hash.
I know you can connect to the (WPA2) network with just the PSK, so it won't 
prevent connecting to it, if that value is known.
If I wanted to allow a friend access to the same wireless network, I could 
give the PSK, without revealing my actual passphrase, which _feels_ more 
secure. (Which may be a false sense of security, which is actually worse)

> What I am proposing actually encrypts the passphrase/PSK using a secret
> key, only known to the IWD systemd service.

My reasoning was that if the request/interest came from people equally 
'clueless' as I am, then not seeing the plain-text passphrase, but only the 
'hash'/PSK, is what they were actually asking.

If it was from knowledgeable people, then yes, actual encryption is very 
likely what they were after.

HTH,
  Diederik

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [RFC 0/2] Encrypt secrets using systemd provided key

[Diederik de Haas]

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

On vrijdag 21 januari 2022 23:36:29 CET Marcel Holtmann wrote:
> > I did/do wonder why my passphrase is stored in plain-text and not in a
> > form which I can get through the wpa_passphrase* utility (I don't know the
> > proper term for it though). Maybe that's what others have been interested
> > in too?
> 
> because starting with WPA3, that doesn’t work anymore.

Thanks for that, I didn't know that.

I'll leave the rest of the discussion up to others :)

Cheers,
  Diederik

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [RFC 0/2] Encrypt secrets using systemd provided key

[Marcel Holtmann]

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

Hi Diederik,

>> There has been interest in enabling IWD users to store their network
>> credentials in some encrypted form.
> 
> I did/do wonder why my passphrase is stored in plain-text and not in a form 
> which I can get through the wpa_passphrase* utility (I don't know the proper 
> term for it though). Maybe that's what others have been interested in too?

because starting with WPA3, that doesn’t work anymore.

Regards

Marcel

Re: [RFC 0/2] Encrypt secrets using systemd provided key

[James Prestwood]

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

Hi Diederik,

On Fri, 2022-01-21 at 23:22 +0100, Diederik de Haas wrote:
> On vrijdag 21 januari 2022 01:41:28 CET James Prestwood wrote:
> > There has been interest in enabling IWD users to store their
> > network
> > credentials in some encrypted form.
> 
> I did/do wonder why my passphrase is stored in plain-text and not in
> a form 
> which I can get through the wpa_passphrase* utility (I don't know the
> proper 
> term for it though). Maybe that's what others have been interested in
> too?

I was unfamiliar with wpa_passphrase until now, but all that appears to
be doing is deriving a PSK from the SSID/passphrase, not 'encrypted' by
any means. In IWD this is "PreSharedKey" in the profile. Ultimately
(for WPA2) you only need the PSK to connect to a network so storing the
PSK directly is just as insecure as the passphrase.

What I am proposing actually encrypts the passphrase/PSK using a secret
key, only known to the IWD systemd service.

> 
> That appears to be a far simpler solution and also wouldn't have the 
> 'transportation' issue Marcel indicated (IIUC).
> 
> Regards,
>   Diederik
> 
> *) having such a utility as part of iwd seems beneficial, otherwise
> I'd still 
> need to install wpasupplicant package (on Debian) to have such a
> utility.
> _______________________________________________
> iwd mailing list -- iwd(a)lists.01.org
> To unsubscribe send an email to iwd-leave(a)lists.01.org

Re: [RFC 0/2] Encrypt secrets using systemd provided key

[Diederik de Haas]

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

On vrijdag 21 januari 2022 01:41:28 CET James Prestwood wrote:
> There has been interest in enabling IWD users to store their network
> credentials in some encrypted form.

I did/do wonder why my passphrase is stored in plain-text and not in a form 
which I can get through the wpa_passphrase* utility (I don't know the proper 
term for it though). Maybe that's what others have been interested in too?

That appears to be a far simpler solution and also wouldn't have the 
'transportation' issue Marcel indicated (IIUC).

Regards,
  Diederik

*) having such a utility as part of iwd seems beneficial, otherwise I'd still 
need to install wpasupplicant package (on Debian) to have such a utility.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [RFC 0/2] Encrypt secrets using systemd provided key

[Marcel Holtmann]

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

Hi James,

>>>>> There has been interest in enabling IWD users to store their
>>>>> network
>>>>> credentials in some encrypted form. Recently systemd added
>>>>> support
>>>>> for
>>>>> passing secrets/credentials to services only accessible by the
>>>>> service
>>>>> they are intended. This provides a clean way of obtaining a
>>>>> secret
>>>>> key
>>>>> which IWD can use to encrypt anything it writes to the FS. In
>>>>> addition
>>>>> there is no hard dependency on systemd since the credential is
>>>>> provided
>>>>> as a file (i.e. no Dbus API or linked library etc).
>>>>> 
>>>>> At the moment setting up the IWD service to use this feature
>>>>> will
>>>>> be
>>>>> left up to the user. But setting this up is very straight
>>>>> forward.
>>>>> I
>>>>> used docs for systemd-creds (Example 2):
>>>>> 
>>>>> https://www.freedesktop.org/software/systemd/man/systemd-creds.html
>>>>> 
>>>>> The only difference is the --name argument should be iwd-
>>>>> secret.
>>>>> 
>>>>> Note: systemd version 250 is required.
>>>>> 
>>>>> The reason this is being sent as an RFC is because of some open
>>>>> questions
>>>>> I had and wanted feedback on:
>>>>> 
>>>>> 1. What options specifically do we want encrypted? These
>>>>> patches
>>>>> only
>>>>>    address Passphrase and PreSharedKey but really any option
>>>>> could
>>>>> be
>>>>>    encrypted. Obviously we would also want 802.1x secrets, but
>>>>> are
>>>>> there
>>>>>    other non-obvious options with privacy concerns?
>>>> 
>>>> we only need to encrypt things that are provided by the user. If
>>>> we
>>>> wouldn’t ask the user for it, then it is not worth while
>>>> protecting.
>>> 
>>> Ok, another option would be encrypting the entire [Security] group
>>> and
>>> assume anything here should be secure. This would actually make
>>> things
>>> quite a bit cleaner, and may be the only solution with how we do
>>> the
>>> 802.1x profiles since they are recursive.
>> 
>> any setting that gets asked by the user via the agent is worth
>> protecting, the rest is not worth it.
>> 
>> As pointed out in the other review, you need to also have some sort
>> of random nounce stored in plaintext. So besides the
>> PassphraseEncrypted, you also need PassphraseSalt or similar. And
>> then your salt value + SSID for example will be used as IV/Nounce
>> into the crypto.
> 
> Yes I realized this after sending it.
> 
>> 
>>>>> 2. What is the stance on existing provisioning files? Currently
>>>>> these
>>>>>    changes overwrite any existing files with the new *Encrypted
>>>>> options
>>>>>    automatically. Is this desirable? or should user have to
>>>>> opt-in
>>>>> their
>>>>>    existing provisioning files.
>>>> 
>>>> The problem arises that you no longer can move from one machine
>>>> to
>>>> the next without re-entering your secrets. So I guess this only
>>>> desirable if the master key is part of your users keyring. If you
>>>> have 200 PSKs entered and you set up a new machine, you now end
>>>> up
>>>> having to re-enter these as you go visiting new networks.
>>> 
>>> How would this work though? The user would have to either manually
>>> encrypt the settings/group or have some way to tell IWD to do it?
>>> 
>>> I think the act of enabling the main.conf option would be enough,
>>> and
>>> we could emphasise this in the docs. Yes this means you cannot go
>>> back
>>> but if you really had 200 profiles you absolutely could not lose
>>> you
>>> probably should have those saved somewhere else, offline.
>>> 
>>> Also, really the only security benefit (above what we do now) is
>>> when
>>> using a TPM meaning you couldn't move the profiles between machines
>>> regardless.
>> 
>> So this is pretty neat for embedded devices. Let say you have a
>> weight scale with WiFi. This way you can ensure with a single system
>> key that all your credentials are protected. If you throw the device
>> away or brick it, it ensures that nobody can easily read it out by
>> just mounting the disk/flash.
>> 
>> For a desktop system it is ok, if you have a capable admin/user that
>> knows what they are doing. If you don’t they are going to scream at
>> your if they move to a new system and all their WiFi is gone. If a
>> MacBook or iPhone upgrade of mine would loose me all my PSKs, I would
>> be rather mad at somebody.
> 
> Yeah I see how this could upset someone, I'm just not sure how we
> accomplish this in a clean way. Either the user has to manually encrypt
> it (which is awful), or we need to provide an additional setting or API
> to say "I want to encrypt this" (which just feels redundant since
> they've set the main.conf option already).

I don’t have an answer for this, I am just pointing it out as a major detail that needs to be documented in big letters.

Regards

Marcel

Re: [RFC 0/2] Encrypt secrets using systemd provided key

[James Prestwood]

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

Hi Marcel,

On Fri, 2022-01-21 at 21:35 +0100, Marcel Holtmann wrote:
> Hi James,
> 
> > > > There has been interest in enabling IWD users to store their
> > > > network
> > > > credentials in some encrypted form. Recently systemd added
> > > > support
> > > > for
> > > > passing secrets/credentials to services only accessible by the
> > > > service
> > > > they are intended. This provides a clean way of obtaining a
> > > > secret
> > > > key
> > > > which IWD can use to encrypt anything it writes to the FS. In
> > > > addition
> > > > there is no hard dependency on systemd since the credential is
> > > > provided
> > > > as a file (i.e. no Dbus API or linked library etc).
> > > > 
> > > > At the moment setting up the IWD service to use this feature
> > > > will
> > > > be
> > > > left up to the user. But setting this up is very straight
> > > > forward.
> > > > I
> > > > used docs for systemd-creds (Example 2):
> > > > 
> > > > https://www.freedesktop.org/software/systemd/man/systemd-creds.html
> > > > 
> > > > The only difference is the --name argument should be iwd-
> > > > secret.
> > > > 
> > > > Note: systemd version 250 is required.
> > > > 
> > > > The reason this is being sent as an RFC is because of some open
> > > > questions
> > > > I had and wanted feedback on:
> > > > 
> > > > 1. What options specifically do we want encrypted? These
> > > > patches
> > > > only
> > > >    address Passphrase and PreSharedKey but really any option
> > > > could
> > > > be
> > > >    encrypted. Obviously we would also want 802.1x secrets, but
> > > > are
> > > > there
> > > >    other non-obvious options with privacy concerns?
> > > 
> > > we only need to encrypt things that are provided by the user. If
> > > we
> > > wouldn’t ask the user for it, then it is not worth while
> > > protecting.
> > 
> > Ok, another option would be encrypting the entire [Security] group
> > and
> > assume anything here should be secure. This would actually make
> > things
> > quite a bit cleaner, and may be the only solution with how we do
> > the
> > 802.1x profiles since they are recursive.
> 
> any setting that gets asked by the user via the agent is worth
> protecting, the rest is not worth it.
> 
> As pointed out in the other review, you need to also have some sort
> of random nounce stored in plaintext. So besides the
> PassphraseEncrypted, you also need PassphraseSalt or similar. And
> then your salt value + SSID for example will be used as IV/Nounce
> into the crypto.

Yes I realized this after sending it.

> 
> > > > 2. What is the stance on existing provisioning files? Currently
> > > > these
> > > >    changes overwrite any existing files with the new *Encrypted
> > > > options
> > > >    automatically. Is this desirable? or should user have to
> > > > opt-in
> > > > their
> > > >    existing provisioning files.
> > > 
> > > The problem arises that you no longer can move from one machine
> > > to
> > > the next without re-entering your secrets. So I guess this only
> > > desirable if the master key is part of your users keyring. If you
> > > have 200 PSKs entered and you set up a new machine, you now end
> > > up
> > > having to re-enter these as you go visiting new networks.
> > 
> > How would this work though? The user would have to either manually
> > encrypt the settings/group or have some way to tell IWD to do it?
> > 
> > I think the act of enabling the main.conf option would be enough,
> > and
> > we could emphasise this in the docs. Yes this means you cannot go
> > back
> > but if you really had 200 profiles you absolutely could not lose
> > you
> > probably should have those saved somewhere else, offline.
> > 
> > Also, really the only security benefit (above what we do now) is
> > when
> > using a TPM meaning you couldn't move the profiles between machines
> > regardless.
> 
> So this is pretty neat for embedded devices. Let say you have a
> weight scale with WiFi. This way you can ensure with a single system
> key that all your credentials are protected. If you throw the device
> away or brick it, it ensures that nobody can easily read it out by
> just mounting the disk/flash.
> 
> For a desktop system it is ok, if you have a capable admin/user that
> knows what they are doing. If you don’t they are going to scream at
> your if they move to a new system and all their WiFi is gone. If a
> MacBook or iPhone upgrade of mine would loose me all my PSKs, I would
> be rather mad at somebody.

Yeah I see how this could upset someone, I'm just not sure how we
accomplish this in a clean way. Either the user has to manually encrypt
it (which is awful), or we need to provide an additional setting or API
to say "I want to encrypt this" (which just feels redundant since
they've set the main.conf option already).

> 
> This is for paranoid people and really only helps if you use a TPM.
> That all said, it is nice feature.
> 
> Regards
> 
> Marcel
> 

Re: [RFC 0/2] Encrypt secrets using systemd provided key

[Marcel Holtmann]

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

Hi James,

>>> There has been interest in enabling IWD users to store their
>>> network
>>> credentials in some encrypted form. Recently systemd added support
>>> for
>>> passing secrets/credentials to services only accessible by the
>>> service
>>> they are intended. This provides a clean way of obtaining a secret
>>> key
>>> which IWD can use to encrypt anything it writes to the FS. In
>>> addition
>>> there is no hard dependency on systemd since the credential is
>>> provided
>>> as a file (i.e. no Dbus API or linked library etc).
>>> 
>>> At the moment setting up the IWD service to use this feature will
>>> be
>>> left up to the user. But setting this up is very straight forward.
>>> I
>>> used docs for systemd-creds (Example 2):
>>> 
>>> https://www.freedesktop.org/software/systemd/man/systemd-creds.html
>>> 
>>> The only difference is the --name argument should be iwd-secret.
>>> 
>>> Note: systemd version 250 is required.
>>> 
>>> The reason this is being sent as an RFC is because of some open
>>> questions
>>> I had and wanted feedback on:
>>> 
>>> 1. What options specifically do we want encrypted? These patches
>>> only
>>>    address Passphrase and PreSharedKey but really any option could
>>> be
>>>    encrypted. Obviously we would also want 802.1x secrets, but are
>>> there
>>>    other non-obvious options with privacy concerns?
>> 
>> we only need to encrypt things that are provided by the user. If we
>> wouldn’t ask the user for it, then it is not worth while protecting.
> 
> Ok, another option would be encrypting the entire [Security] group and
> assume anything here should be secure. This would actually make things
> quite a bit cleaner, and may be the only solution with how we do the
> 802.1x profiles since they are recursive.

any setting that gets asked by the user via the agent is worth protecting, the rest is not worth it.

As pointed out in the other review, you need to also have some sort of random nounce stored in plaintext. So besides the PassphraseEncrypted, you also need PassphraseSalt or similar. And then your salt value + SSID for example will be used as IV/Nounce into the crypto.

>>> 2. What is the stance on existing provisioning files? Currently
>>> these
>>>    changes overwrite any existing files with the new *Encrypted
>>> options
>>>    automatically. Is this desirable? or should user have to opt-in
>>> their
>>>    existing provisioning files.
>> 
>> The problem arises that you no longer can move from one machine to
>> the next without re-entering your secrets. So I guess this only
>> desirable if the master key is part of your users keyring. If you
>> have 200 PSKs entered and you set up a new machine, you now end up
>> having to re-enter these as you go visiting new networks.
> 
> How would this work though? The user would have to either manually
> encrypt the settings/group or have some way to tell IWD to do it?
> 
> I think the act of enabling the main.conf option would be enough, and
> we could emphasise this in the docs. Yes this means you cannot go back
> but if you really had 200 profiles you absolutely could not lose you
> probably should have those saved somewhere else, offline.
> 
> Also, really the only security benefit (above what we do now) is when
> using a TPM meaning you couldn't move the profiles between machines
> regardless.

So this is pretty neat for embedded devices. Let say you have a weight scale with WiFi. This way you can ensure with a single system key that all your credentials are protected. If you throw the device away or brick it, it ensures that nobody can easily read it out by just mounting the disk/flash.

For a desktop system it is ok, if you have a capable admin/user that knows what they are doing. If you don’t they are going to scream at your if they move to a new system and all their WiFi is gone. If a MacBook or iPhone upgrade of mine would loose me all my PSKs, I would be rather mad at somebody.

This is for paranoid people and really only helps if you use a TPM. That all said, it is nice feature.

Regards

Marcel

Re: [RFC 0/2] Encrypt secrets using systemd provided key

[James Prestwood]

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

Hi Marcel,

On Fri, 2022-01-21 at 16:20 +0100, Marcel Holtmann wrote:
> Hi James,
> 
> > There has been interest in enabling IWD users to store their
> > network
> > credentials in some encrypted form. Recently systemd added support
> > for
> > passing secrets/credentials to services only accessible by the
> > service
> > they are intended. This provides a clean way of obtaining a secret
> > key
> > which IWD can use to encrypt anything it writes to the FS. In
> > addition
> > there is no hard dependency on systemd since the credential is
> > provided
> > as a file (i.e. no Dbus API or linked library etc).
> > 
> > At the moment setting up the IWD service to use this feature will
> > be
> > left up to the user. But setting this up is very straight forward.
> > I
> > used docs for systemd-creds (Example 2):
> > 
> > https://www.freedesktop.org/software/systemd/man/systemd-creds.html
> > 
> > The only difference is the --name argument should be iwd-secret.
> > 
> > Note: systemd version 250 is required.
> > 
> > The reason this is being sent as an RFC is because of some open
> > questions
> > I had and wanted feedback on:
> > 
> > 1. What options specifically do we want encrypted? These patches
> > only
> >    address Passphrase and PreSharedKey but really any option could
> > be
> >    encrypted. Obviously we would also want 802.1x secrets, but are
> > there
> >    other non-obvious options with privacy concerns?
> 
> we only need to encrypt things that are provided by the user. If we
> wouldn’t ask the user for it, then it is not worth while protecting.

Ok, another option would be encrypting the entire [Security] group and
assume anything here should be secure. This would actually make things
quite a bit cleaner, and may be the only solution with how we do the
802.1x profiles since they are recursive.

> 
> > 2. What is the stance on existing provisioning files? Currently
> > these
> >    changes overwrite any existing files with the new *Encrypted
> > options
> >    automatically. Is this desirable? or should user have to opt-in
> > their
> >    existing provisioning files.
> 
> The problem arises that you no longer can move from one machine to
> the next without re-entering your secrets. So I guess this only
> desirable if the master key is part of your users keyring. If you
> have 200 PSKs entered and you set up a new machine, you now end up
> having to re-enter these as you go visiting new networks.

How would this work though? The user would have to either manually
encrypt the settings/group or have some way to tell IWD to do it?

I think the act of enabling the main.conf option would be enough, and
we could emphasise this in the docs. Yes this means you cannot go back
but if you really had 200 profiles you absolutely could not lose you
probably should have those saved somewhere else, offline.

Also, really the only security benefit (above what we do now) is when
using a TPM meaning you couldn't move the profiles between machines
regardless.

> 
> > 3. Is the secret provided via a file enough? (the secret is still
> > stored
> >    as plaintext *somewhere*, though systemd limits permissions).
> > Systemd
> >    supports an IPC mechanism to obtain the secret. Is this more
> > secure?
> 
> From iwd perspective it is always a file. systemd does the reading
> from an AF_UNIX socket and storing it as a file. When IPC part
> becomes interesting if you want to provide an iwd-secrets-provider
> tool.
> 
> Note: At least that is how I understood the man page. I have not
> verified this in the systemd sources.
> 
> > 4. Should full provisioning file encryption be optional/supported?
> > I felt
> >    it was best to only encrypt sensitive options like
> > PSK/Passphrase which
> >    would allow editing of the provisioning file without extra steps
> > of
> >    decrypting, editing, and encrypting. I think this is above the
> > capability
> >    or desire of most users.
> > 
> >    If, though, a provisioning file is never expected to change or
> > issued by
> >    a network administrator that does not want it edited I could see
> > full
> >    file encryption being ok.
> 
> What you want is that system / networks admins can sign their
> provision file and you would verify that it is unmodified. That is
> generally useful as well, but we would need to discuss where the
> certificate that you verify against comes from.
> 
> Regards
> 
> Marcel
> 

Re: [RFC 0/2] Encrypt secrets using systemd provided key

[Marcel Holtmann]

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

Hi James,

> There has been interest in enabling IWD users to store their network
> credentials in some encrypted form. Recently systemd added support for
> passing secrets/credentials to services only accessible by the service
> they are intended. This provides a clean way of obtaining a secret key
> which IWD can use to encrypt anything it writes to the FS. In addition
> there is no hard dependency on systemd since the credential is provided
> as a file (i.e. no Dbus API or linked library etc).
> 
> At the moment setting up the IWD service to use this feature will be
> left up to the user. But setting this up is very straight forward. I
> used docs for systemd-creds (Example 2):
> 
> https://www.freedesktop.org/software/systemd/man/systemd-creds.html
> 
> The only difference is the --name argument should be iwd-secret.
> 
> Note: systemd version 250 is required.
> 
> The reason this is being sent as an RFC is because of some open questions
> I had and wanted feedback on:
> 
> 1. What options specifically do we want encrypted? These patches only
>    address Passphrase and PreSharedKey but really any option could be
>    encrypted. Obviously we would also want 802.1x secrets, but are there
>    other non-obvious options with privacy concerns?

we only need to encrypt things that are provided by the user. If we wouldn’t ask the user for it, then it is not worth while protecting.

> 2. What is the stance on existing provisioning files? Currently these
>    changes overwrite any existing files with the new *Encrypted options
>    automatically. Is this desirable? or should user have to opt-in their
>    existing provisioning files.

The problem arises that you no longer can move from one machine to the next without re-entering your secrets. So I guess this only desirable if the master key is part of your users keyring. If you have 200 PSKs entered and you set up a new machine, you now end up having to re-enter these as you go visiting new networks.

> 3. Is the secret provided via a file enough? (the secret is still stored
>    as plaintext *somewhere*, though systemd limits permissions). Systemd
>    supports an IPC mechanism to obtain the secret. Is this more secure?

>From iwd perspective it is always a file. systemd does the reading from an AF_UNIX socket and storing it as a file. When IPC part becomes interesting if you want to provide an iwd-secrets-provider tool.

Note: At least that is how I understood the man page. I have not verified this in the systemd sources.

> 4. Should full provisioning file encryption be optional/supported? I felt
>    it was best to only encrypt sensitive options like PSK/Passphrase which
>    would allow editing of the provisioning file without extra steps of
>    decrypting, editing, and encrypting. I think this is above the capability
>    or desire of most users.
> 
>    If, though, a provisioning file is never expected to change or issued by
>    a network administrator that does not want it edited I could see full
>    file encryption being ok.

What you want is that system / networks admins can sign their provision file and you would verify that it is unmodified. That is generally useful as well, but we would need to discuss where the certificate that you verify against comes from.

Regards

Marcel