On 7/13/20 6:23 AM, Tuong Tong Lien wrote:
Hi Jon,
Please see my feedback inline.
-----Original Message-----
From: Jon Maloy <jma...@redhat.com>
Sent: Saturday, July 11, 2020 1:38 AM
To: Tuong Tong Lien <tuong.t.l...@dektech.com.au>; ma...@donjonn.com;
ying....@windriver.com; tipc-
discuss...@lists.sourceforge.net
Cc: tipc-dek <tipc-...@dektech.com.au>
Subject: Re: [PATCH RFC 0/5] tipc: add more features to TIPC encryption
On 7/10/20 6:11 AM, Tuong Lien wrote:
Hi Jon/all,
As mentioned, I'd like to share the series that I have added some new
features in order to complete the TIPC encryption:
- Patch 1 ("tipc: fix using smp_processor_id() in preemptible"):
- Patch 2 ("tipc: optimize key switching time and logic"):
These two patches just do a bug-fix and optimization for the code as
a preparation for later commits.
- Patch 3 ("tipc: introduce encryption master key"):
This will introduce a 'master key' support which is set by user as a
'long-term' or static key (e.g. shared between nodes in the cluster in
user control way). It will act like a key encryption key for the later
key exchange, as well as allow a new node joins the cluster while it
has no knowledge of current active session keys in the existing nodes.
The master key setting will use the same 'tipc node set key' command
but with a 'master' flag (see below).
- Patch 4 ("tipc: add automatic session key exchange"):
TX key of a node will now be able to be exchanged to peer nodes (
encrypted/decrypted by the master key) and attached as the
corresponding RX keys automatically. A node can also 'request' for a TX
key from peer whenever needed.
This will enable us to do the later rekeying, and also make a new node
being able to obtain the session keys from existing nodes.
- Patch 5 ("tipc: add automatic rekeying for encryption key"):
Finally, this patch will add the automatic rekeying which will generate
a session key on each node at a specific interval. The key will be
also distributed automatically to peer nodes, so it will be switched to
be active shortly and traffic will be finally encrypted/decrypted by
that new key.
The rekeying interval is configurable as well, also user can disable or
trigger an immediate rekeying if he wants.
Besides, there will be a patch in the 'iproute2/tipc' including the new
'tipc node set key' command options, basically it will look like this:
---------
$tipc node set key --help
Usage: tipc node set key KEY [algname ALGNAME] [PROPERTIES]
tipc node set key rekeying REKEYING
KEY
Symmetric KEY & SALT as a composite ASCII or hex string (0x...) in form:
[KEY: 16, 24 or 32 octets][SALT: 4 octets]
ALGNAME
Cipher algorithm [default: "gcm(aes)"]
PROPERTIES
master - Set KEY as a cluster master key
<empty> - Set KEY as a cluster key
nodeid NODEID - Set KEY as a per-node key for own or peer
REKEYING
INTERVAL - Set rekeying interval (in minutes) [0: disable]
now - Trigger one (first) rekeying immediately
EXAMPLES
tipc node set key 0x746869735F69735F615F6B657931365F73616C74
tipc node set key this_is_a_key16_salt algname "gcm(aes)" nodeid 1001002
tipc node set key this_is_a_master_key master rekeying now
tipc node set key rekeying 600
---------
So, please help check the patches and give your comments, thanks a lot!
BR/Tuong
I haven't reviewed this yet, but still have a comment and a question.
1) It would sound less scary if we call this a "cluster key" instead of
a "master key"
Yes, in terms of encryption/decryption, a "master key" is actually a "cluster
key" (because the same key will be used for both TX/RX in cluster...) but it is a bit
different from our traditional cluster or per-node key concepts in terms of use or key management,
especially by the following points:
- The master key will not be used for data or traffic encryption like our traditional
keys, but act like a "key-encryption key" to encrypt those subordinate data
keys (i.e. in the key exchange).
- The master key should be a long-term or static key, instead of the traditional ones
which will be "ephemeral" (i.e. in the rekeying...).
- The master key will allow a new node to join the cluster when it completely doesn't
know what the current active (ephemeral) keys in the existing nodes. It will also act
like an "authentication" key, so ensure that the new node has the right
authenticity first.
- The master key will be almost the only key that needs to be provided by (privileged)
user, along with the other automatic key mechanisms we provide here,
"ephemeral" keys will be generated/used for all the TIPC traffic encryption
frequently, so getting a higher secure level.
So, I think we can call it as a "cluster master key", just to distinguish it from the
"cluster key" while still retain its nature 😊.
Or just "authentication key", even if that is not the whole truth. The
regular encryption keys can be referred to as session keys.
2) Do you have any thoughts about how we can replace this key if it ever
gets compromised?
To me it sounds like will need a user space TLS based framework
after all to achieve this.
Yes, I have thought about this. It will require a "framework" for setting or updating the
same master key in the cluster, but it will be much simpler now since that is the only one we need
(as said above)... In a secure system, I believe they had such a framework already, like a
"security service" for the whole cluster system (used for SSH, CLI, etc... not only
TIPC), for example: the key can be simply stored in a private/protected directory or database which
is shared between nodes in the cluster. So once it is updated, the key will be sent to TIPC and set
as the master key, that's it.
In general, the achievement from these commits is to make things much
convenient for user (he just needs to set the master key...) but help increase
the security for TIPC encryption since the traffic encryption keys can be
replaced very frequently now...
BR/Tuong
Yes, I totally agree. I will review this later this week.
///jon
Regards
///jon
Tuong Lien (5):
tipc: fix using smp_processor_id() in preemptible
tipc: optimize key switching time and logic
tipc: introduce encryption master key
tipc: add automatic session key exchange
tipc: add automatic rekeying for encryption key
include/uapi/linux/tipc.h | 2 +
include/uapi/linux/tipc_netlink.h | 2 +
net/tipc/crypto.c | 986
++++++++++++++++++++++++++++----------
net/tipc/crypto.h | 41 +-
net/tipc/link.c | 5 +
net/tipc/msg.h | 10 +-
net/tipc/netlink.c | 2 +
net/tipc/node.c | 89 ++--
net/tipc/node.h | 2 +
net/tipc/sysctl.c | 9 +
10 files changed, 862 insertions(+), 286 deletions(-)
_______________________________________________
tipc-discussion mailing list
tipc-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tipc-discussion
