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 😊.
> 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
>
> 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
