11:41 a.m.
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
11:41 a.m.
New subject: [RFC 1/2] main: add SystemdEncrypt option, and initialize key
Recently systemd added the ability to pass secret credentials to
services via LoadCredentialEncrypted/SetCredentialEncrypted. Once
set up the service is able to read the decrypted credentials from
a file. The file path is found in the environment variable
CREDENTIALS_DIRECTORY + an identifier. The ID used by IWD is
iwd-secret, and the service file should be configured as such.
A new boolean option was added to main.conf: SystemdEncrypt.
When true IWD will attempt to read the decrypted secret from
systemd. If at any point this fails warnings will be printed but
IWD will continue normally. Its expected that any failures will
result in the inability to connect to any networks which have
previously encrypted the passphrase/PSK without re-entering
the passphrase manually. This could happen, for example, if the
systemd secret was changed.
Once the secret is read in, it is hashed, and made available to
modules via iwd_get_system_key(). This can be used as a key
to encrypt sensitive data IWD stores on disk such as the network
PSK/passphrase, EAP credentials etc.
---
src/iwd.h | 1 +
src/main.c | 64 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 65 insertions(+)
diff --git a/src/iwd.h b/src/iwd.h
index 1be20df3..4aa792de 100644
--- a/src/iwd.h
+++ b/src/iwd.h
@@ -33,6 +33,7 @@ struct l_genl_family;
const struct l_settings *iwd_get_config(void);
struct l_genl *iwd_get_genl(void);
struct l_netlink *iwd_get_rtnl(void);
+const unsigned char *iwd_get_system_key(size_t *len);
void netdev_shutdown(void);
diff --git a/src/main.c b/src/main.c
index d0dbedc8..c0b8b7c3 100644
--- a/src/main.c
+++ b/src/main.c
@@ -29,6 +29,7 @@
#include <errno.h>
#include <getopt.h>
#include <signal.h>
+#include <sys/stat.h>
#include <ell/ell.h>
#include <ell/useful.h>
@@ -60,6 +61,7 @@ static const char *debugopt;
static bool developeropt;
static bool terminating;
static bool nl80211_complete;
+static unsigned char system_key[32];
static void main_loop_quit(struct l_timeout *timeout, void *user_data)
{
@@ -130,6 +132,16 @@ const char *iwd_get_phy_blacklist(void)
return nophys;
}
+const unsigned char *iwd_get_system_key(size_t *len)
+{
+ if (l_memeqzero(system_key, sizeof(system_key)))
+ return NULL;
+
+ *len = sizeof(system_key);
+
+ return system_key;
+}
+
bool iwd_is_developer_mode(void)
{
return developeropt;
@@ -397,6 +409,56 @@ done:
return r;
}
+/*
+ * Initialize a systemd encryption key for encrypting/decrypting credentials.
+ * IWD expects a key ID of "iwd-secret". Creating this key is left up to the
+ * user/systemd.
+ */
+static void setup_system_key(void)
+{
+ bool enabled;
+ _auto_(l_free) char *path = NULL;
+ const char *cred_dir;
+ ssize_t len;
+ struct stat st;
+ _auto_(l_free) uint8_t *key = NULL;
+ struct l_checksum *sha;
+
+ if (!l_settings_get_bool(iwd_config, "General", "SystemdEncrypt",
+ &enabled) || !enabled)
+ return;
+
+ cred_dir = getenv("CREDENTIALS_DIRECTORY");
+ if (!cred_dir) {
+ l_warn("SystemdEncrypt enabled, but CREDENTIALS_DIRECTORY not "
+ "set, check iwd.service file");
+ return;
+ }
+
+ path = l_strdup_printf("%s/iwd-secret", cred_dir);
+
+ if (stat(path, &st) < 0) {
+ l_warn("SystemdEncrypt enabled, but could not stat %s",
+ path);
+ return;
+ }
+
+ key = l_malloc(st.st_size);
+
+ len = read_file(key, st.st_size, "%s", path);
+ if (len < 0) {
+ l_warn("SystemdEncrypt enabled, but reading %s failed (%ld)",
+ path, len);
+ return;
+ }
+
+ sha = l_checksum_new(L_CHECKSUM_SHA256);
+
+ l_checksum_update(sha, key, st.st_size);
+ l_checksum_get_digest(sha, system_key, sizeof(system_key));
+ l_checksum_free(sha);
+}
+
int main(int argc, char *argv[])
{
int exit_status;
@@ -529,6 +591,8 @@ int main(int argc, char *argv[])
l_dbus_set_disconnect_handler(dbus, dbus_disconnected, NULL, NULL);
dbus_init(dbus);
+ setup_system_key();
+
exit_status = l_main_run_with_signal(signal_handler, NULL);
iwd_modules_exit();
--
2.31.1
11:41 a.m.
New subject: [RFC 2/2] network: add support for encrypted Passphrase/PSK
Two keys were added: PreSharedKeyEncrypted, PassphraseEncrypted which
are now automatically set/loaded if SystemdEncrypt=true.
When transitioning to this option any existing provisioning files will
be read in as plaintext but when synced the *Encrypted options will be
used instead. After that the file will no longer contain any plaintext
psk/passphrase values.
The encryption itself uses AES-CTR with a zero IV. This is to avoid
extra padding and dealing with block sizes. A magic 32 bit value is
prepended to the beginning of the plaintext data to serve as verification
that the decryption succeeded.
If decryption fails for whatever reason the behavior is no different
than if no PSK/Passphrase value was found at all, meaning an agent
request will be required to re-establish the PSK/passphrase or manually
providing the PreSharedKey/Passphrase in plaintext in the provisioning file.
---
src/network.c | 183 ++++++++++++++++++++++++++++++++++++++++++++++++--
1 file changed, 177 insertions(+), 6 deletions(-)
diff --git a/src/network.c b/src/network.c
index 10937ab7..89d6b8e2 100644
--- a/src/network.c
+++ b/src/network.c
@@ -572,8 +572,108 @@ generate:
return -EIO;
}
+static uint8_t *network_decrypt(const uint8_t *key, size_t key_len,
+ void *encrypted, size_t len, size_t *len_out)
+{
+ struct l_cipher *aes;
+ uint8_t iv[16] = { 0 };
+ uint32_t magic = 0x0abcdef0;
+ uint8_t *out;
+
+ aes = l_cipher_new(L_CIPHER_AES_CTR, key, key_len);
+ l_cipher_set_iv(aes, iv, sizeof(iv));
+
+ out = l_malloc(len);
+
+ l_cipher_decrypt(aes, encrypted, out, len);
+
+ if (memcmp(out, &magic, 4)) {
+ l_free(out);
+ return NULL;
+ }
+
+ memmove(out, out + 4, len - 4);
+
+ *len_out = len - 4;
+
+ return out;
+}
+
+static int network_decrypt_secrets(const uint8_t *key, size_t key_len,
+ struct network *network,
+ uint8_t **psk, size_t *psk_len,
+ char **passphrase)
+{
+ uint8_t *encrypted;
+ size_t elen, dlen;
+ uint8_t *psk_out = NULL;
+ size_t psk_len_out = 0;
+ char *passphrase_out = NULL;
+
+ if (*psk || *passphrase) {
+ /*
+ * Likely the first time running IWD after SystemdEncrypt was
+ * enabled. Let network_load_psk process the psk/passphrase in
+ * plaintext but set sync_settings so they will be force written
+ * to disk as the *Encrypted options.
+ *
+ * Someone could have manually added Passphrase/PreSharedKey
+ * back into the file too but either way sync the settings.
+ */
+ network->sync_settings = true;
+ return 0;
+ }
+
+ encrypted = l_settings_get_bytes(network->settings, "Security",
+ "PreSharedKeyEncrypted", &elen);
+ if (encrypted) {
+ psk_out = network_decrypt(key, key_len, encrypted,
+ elen, &psk_len_out);
+ if (!psk_out) {
+ l_error("Decryption failed for PreSharedKey");
+ l_free(encrypted);
+ return -ENOKEY;
+ }
+
+ l_free(encrypted);
+ }
+
+ encrypted = l_settings_get_bytes(network->settings, "Security",
+ "PassphraseEncrypted", &elen);
+ if (encrypted) {
+ uint8_t *p = network_decrypt(key, key_len, encrypted,
+ elen, &dlen);
+ if (!p) {
+ l_error("Decryption failed for Passphrase");
+ l_free(encrypted);
+ return -ENOKEY;
+ }
+
+ passphrase_out = l_malloc(dlen + 1);
+ memcpy(passphrase_out, p, dlen);
+ passphrase_out[dlen] = '\0';
+
+ l_free(p);
+ l_free(encrypted);
+ }
+
+ if (psk)
+ *psk = psk_out;
+
+ if (psk_len)
+ *psk_len = psk_len_out;
+
+ if (passphrase)
+ *passphrase = passphrase_out;
+
+ return 0;
+}
+
static int network_load_psk(struct network *network, bool need_passphrase)
{
+ size_t key_len;
+ const uint8_t *key = iwd_get_system_key(&key_len);
+ int ret;
const char *ssid = network_get_ssid(network);
enum security security = network_get_security(network);
size_t psk_len;
@@ -586,6 +686,13 @@ static int network_load_psk(struct network *network, bool
need_passphrase)
_auto_(l_free) char *path =
storage_get_network_file_path(security, ssid);
+ if (key) {
+ ret = network_decrypt_secrets(key, key_len, network,
+ &psk, &psk_len, &passphrase);
+ if (ret < 0)
+ return ret;
+ }
+
if (psk && psk_len != 32) {
l_error("%s: invalid PreSharedKey format", path);
l_free(psk);
@@ -639,9 +746,69 @@ static void network_settings_save_sae_pt_ecc(struct l_settings
*settings,
l_settings_set_bytes(settings, "Security", key, buf, len);
}
+/*
+ * Using AES-CTR to with a zero IV to avoid dealing with padding as opposed to
+ * regular AES. 4 magic bytes are prepended to the plaintext bytes to act as
+ * verification when the data is decrypted.
+ */
+static uint8_t *network_encrypt(const uint8_t *key, size_t key_len,
+ void *decrypted, size_t len, size_t *len_out)
+{
+ struct l_cipher *aes;
+ uint8_t iv[16] = { 0 };
+ uint32_t magic = 0x0abcdef0;
+ uint8_t in[len + 4];
+ uint8_t *out;
+
+ aes = l_cipher_new(L_CIPHER_AES_CTR, key, key_len);
+ l_cipher_set_iv(aes, iv, sizeof(iv));
+
+ memcpy(in, &magic, 4);
+ memcpy(in + 4, decrypted, len);
+
+ out = l_malloc(len + 4);
+
+ l_cipher_encrypt(aes, in, out, len + 4);
+
+ *len_out = len + 4;
+
+ return out;
+}
+
+static void network_encrypt_secrets(const uint8_t *key, size_t len,
+ struct network *network,
+ struct l_settings *settings)
+{
+ uint8_t *enc;
+ size_t enc_len;
+
+ if (network->psk) {
+ enc = network_encrypt(key, len, network->psk, 32, &enc_len);
+
+ l_settings_set_bytes(settings, "Security",
+ "PreSharedKeyEncrypted", enc, enc_len);
+
+ l_free(enc);
+ }
+
+ if (network->passphrase) {
+ enc = network_encrypt(key, len, network->passphrase,
+ strlen(network->passphrase), &enc_len);;
+
+ l_settings_set_bytes(settings, "Security",
+ "PassphraseEncrypted", enc, enc_len);
+
+ l_free(enc);
+ }
+
+}
+
static void network_settings_save(struct network *network,
struct l_settings *settings)
{
+ size_t key_len;
+ const uint8_t *encrypt_key = iwd_get_system_key(&key_len);
+
if (network->have_transition_disable) {
char *modes[4];
unsigned int i = 0;
@@ -670,13 +837,17 @@ static void network_settings_save(struct network *network,
/* We only update the [Security] bits here, wipe the group first */
l_settings_remove_group(settings, "Security");
- if (network->psk)
- l_settings_set_bytes(settings, "Security", "PreSharedKey",
- network->psk, 32);
+ if (!encrypt_key) {
+ if (network->psk)
+ l_settings_set_bytes(settings, "Security", "PreSharedKey",
+ network->psk, 32);
- if (network->passphrase)
- l_settings_set_string(settings, "Security", "Passphrase",
- network->passphrase);
+ if (network->passphrase)
+ l_settings_set_string(settings, "Security", "Passphrase",
+ network->passphrase);
+ } else
+ network_encrypt_secrets(encrypt_key, key_len, network,
+ settings);
if (network->sae_pt_19)
network_settings_save_sae_pt_ecc(settings, network->sae_pt_19);
--
2.31.1
1:51 a.m.
New subject: [RFC 2/2] network: add support for encrypted Passphrase/PSK
Hi James,
Two keys were added: PreSharedKeyEncrypted, PassphraseEncrypted
which
are now automatically set/loaded if SystemdEncrypt=true.
When transitioning to this option any existing provisioning files will
be read in as plaintext but when synced the *Encrypted options will be
used instead. After that the file will no longer contain any plaintext
psk/passphrase values.
The encryption itself uses AES-CTR with a zero IV. This is to avoid
extra padding and dealing with block sizes. A magic 32 bit value is
prepended to the beginning of the plaintext data to serve as verification
that the decryption succeeded.
If decryption fails for whatever reason the behavior is no different
than if no PSK/Passphrase value was found at all, meaning an agent
request will be required to re-establish the PSK/passphrase or manually
providing the PreSharedKey/Passphrase in plaintext in the provisioning file.
---
src/network.c | 183 ++++++++++++++++++++++++++++++++++++++++++++++++--
1 file changed, 177 insertions(+), 6 deletions(-)
diff --git a/src/network.c b/src/network.c
index 10937ab7..89d6b8e2 100644
--- a/src/network.c
+++ b/src/network.c
@@ -572,8 +572,108 @@ generate:
return -EIO;
}
+static uint8_t *network_decrypt(const uint8_t *key, size_t key_len,
+ void *encrypted, size_t len, size_t *len_out)
+{
+ struct l_cipher *aes;
+ uint8_t iv[16] = { 0 };
+ uint32_t magic = 0x0abcdef0;
+ uint8_t *out;
+
+ aes = l_cipher_new(L_CIPHER_AES_CTR, key, key_len);
+ l_cipher_set_iv(aes, iv, sizeof(iv));
+
+ out = l_malloc(len);
+
+ l_cipher_decrypt(aes, encrypted, out, len);
+
+ if (memcmp(out, &magic, 4)) {
+ l_free(out);
+ return NULL;
+ }
+
+ memmove(out, out + 4, len - 4);
+
+ *len_out = len - 4;
+
+ return out;
+}
+
+static int network_decrypt_secrets(const uint8_t *key, size_t key_len,
+ struct network *network,
+ uint8_t **psk, size_t *psk_len,
+ char **passphrase)
+{
+ uint8_t *encrypted;
+ size_t elen, dlen;
+ uint8_t *psk_out = NULL;
+ size_t psk_len_out = 0;
+ char *passphrase_out = NULL;
+
+ if (*psk || *passphrase) {
+ /*
+ * Likely the first time running IWD after SystemdEncrypt was
+ * enabled. Let network_load_psk process the psk/passphrase in
+ * plaintext but set sync_settings so they will be force written
+ * to disk as the *Encrypted options.
+ *
+ * Someone could have manually added Passphrase/PreSharedKey
+ * back into the file too but either way sync the settings.
+ */
+ network->sync_settings = true;
+ return 0;
+ }
+
+ encrypted = l_settings_get_bytes(network->settings, "Security",
+ "PreSharedKeyEncrypted", &elen);
+ if (encrypted) {
+ psk_out = network_decrypt(key, key_len, encrypted,
+ elen, &psk_len_out);
+ if (!psk_out) {
+ l_error("Decryption failed for PreSharedKey");
+ l_free(encrypted);
+ return -ENOKEY;
+ }
+
+ l_free(encrypted);
+ }
+
+ encrypted = l_settings_get_bytes(network->settings, "Security",
+ "PassphraseEncrypted", &elen);
+ if (encrypted) {
+ uint8_t *p = network_decrypt(key, key_len, encrypted,
+ elen, &dlen);
+ if (!p) {
+ l_error("Decryption failed for Passphrase");
+ l_free(encrypted);
+ return -ENOKEY;
+ }
+
+ passphrase_out = l_malloc(dlen + 1);
+ memcpy(passphrase_out, p, dlen);
+ passphrase_out[dlen] = '\0';
+
+ l_free(p);
+ l_free(encrypted);
+ }
+
+ if (psk)
+ *psk = psk_out;
+
+ if (psk_len)
+ *psk_len = psk_len_out;
+
+ if (passphrase)
+ *passphrase = passphrase_out;
+
+ return 0;
+}
+
static int network_load_psk(struct network *network, bool need_passphrase)
{
+ size_t key_len;
+ const uint8_t *key = iwd_get_system_key(&key_len);
+ int ret;
const char *ssid = network_get_ssid(network);
enum security security = network_get_security(network);
size_t psk_len;
@@ -586,6 +686,13 @@ static int network_load_psk(struct network *network, bool
need_passphrase)
_auto_(l_free) char *path =
storage_get_network_file_path(security, ssid);
+ if (key) {
+ ret = network_decrypt_secrets(key, key_len, network,
+ &psk, &psk_len, &passphrase);
+ if (ret < 0)
+ return ret;
+ }
+
if (psk && psk_len != 32) {
l_error("%s: invalid PreSharedKey format", path);
l_free(psk);
@@ -639,9 +746,69 @@ static void network_settings_save_sae_pt_ecc(struct l_settings
*settings,
l_settings_set_bytes(settings, "Security", key, buf, len);
}
+/*
+ * Using AES-CTR to with a zero IV to avoid dealing with padding as opposed to
+ * regular AES. 4 magic bytes are prepended to the plaintext bytes to act as
+ * verification when the data is decrypted.
+ */
+static uint8_t *network_encrypt(const uint8_t *key, size_t key_len,
+ void *decrypted, size_t len, size_t *len_out)
+{
+ struct l_cipher *aes;
+ uint8_t iv[16] = { 0 };
+ uint32_t magic = 0x0abcdef0;
+ uint8_t in[len + 4];
+ uint8_t *out;
+
+ aes = l_cipher_new(L_CIPHER_AES_CTR, key, key_len);
+ l_cipher_set_iv(aes, iv, sizeof(iv));
+
+ memcpy(in, &magic, 4);
+ memcpy(in + 4, decrypted, len);
this you can not do. You are giving away half of an AES block and would be vulnerable to a
plaintext attack. No part of a plaintext can be predictable.
Regards
Marcel
1:53 a.m.
New subject: [RFC 2/2] network: add support for encrypted Passphrase/PSK
Hi James,
Two keys were added: PreSharedKeyEncrypted, PassphraseEncrypted
which
are now automatically set/loaded if SystemdEncrypt=true.
When transitioning to this option any existing provisioning files will
be read in as plaintext but when synced the *Encrypted options will be
used instead. After that the file will no longer contain any plaintext
psk/passphrase values.
The encryption itself uses AES-CTR with a zero IV. This is to avoid
extra padding and dealing with block sizes. A magic 32 bit value is
prepended to the beginning of the plaintext data to serve as verification
that the decryption succeeded.
so this is a bad idea. If two independent networks happen to use the same passphrase or
PSK, then the encrypted data will be the same. You need to salt the encryption so that
even if the plaintext is the same, the encrypted data is different (give that you use the
same key).
Regards
Marcel
2:20 a.m.
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
7:19 a.m.
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
7:35 a.m.
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
7:49 a.m.
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
7:54 a.m.
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
9:22 a.m.
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.
9:30 a.m.
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
10:46 a.m.
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
9:36 a.m.
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
9:42 a.m.
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
240
days inactive
240
days old
14 comments
3 participants
participants (3)
-
Diederik de Haas -
James Prestwood -
Marcel Holtmann