You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ignite.apache.org by Nikolay Izhikov <ni...@apache.org> on 2018/10/22 19:38:56 UTC
[DISCUSSION] TDE. Phase-2. Master key rotation.
Hello, Igniters.
As you may know, we successfully implement TDE. Phase-1 feature. [1]
This improvement allows users to use an encrypted cache.
To make TDE production ready I propose to extend it with two things:
* Master key rotation.
* Cache key rotation.
Such features required by many security standards such as PCI DSS [2] and GDPR [3]
I think it would be easier to discuss, implement and review both features separately.
So my plan is the following:
* TDE. Phase-2 - Master key rotation [4]
* TDE. Phase-3 - Cache key rotation. [5]
I prepared designs for both parts.
I want to specifically discuss Phase-2 design.
Phase-3 design state is [EARLY DRAFT].
I propose to use Phase-3 design as a reference to make sure we have a consistent view of all aspects of TDE
and can be implemented without significant changes in earlier parts.
Below, my design.
Following changes will be made in confluence [4].
Please, share your feedback.
*TDE. PHASE-2. MASTER KEY ROTATION*
Key rotation required in case of it compromising or at the end of crypto period(key validity period).
Goal:
To implement the ability to rotate master encryption key.
New processes:
1. Master key rotation.
2. Removal of a master key.
New administrator commands:
1. Master keys view: node -> master key hash
2. Cache group keys view: node -> group name -> encryption key hash
MASTER KEY ROTATION:
Process start:
Administrator initiates key rotation via some kind of user interface(CLI, Visor, Web Console, JMX, etc).
Process description:
Message is sent by discovery.
A Message should contain:
* Master cache key encrypted with the current master key.
When server node processed message following actions are executed:
* Blocks creation of encrypted cache key.
* Encrypt cache group keys with new master key.
* Unblock creation of encrypted cache key.
New joining node should also change the current master key with the new one.
Process completion:
The administrator initiates process completion via the interface by using “master key removal” command.
Design assumes an administrator will check that all nodes successfully change master key and all required nodes are alive.
MASTER KEY REMOVAL:
Process start:
Administrator initiates process via some kind of user interface(CLI, Visor, WebConsole, JMX, etc),
Process description:
Message is sent by discovery.
Message should contain:
* New master key hash.
When a server node processed message following actions are executed:
Received master key hash compared with known master key hash.
Previous master key removed using configured EncryptionSPI.
NEW COMMANDS:
Master key hashes.
Input: nothing
Output: List of Tuples3
* Node ID
* Current key hash
* Previous key hash or null.
Cache key hashes.
Input: cache id.
Output: List of Tuples3
* Node ID
* Current key hash
* Previous key hash or null.
[1] https://issues.apache.org/jira/browse/IGNITE-8260
[2] https://www.pcisecuritystandards.org/documents/PCI_DSS_v3-2-1.pdf
[3] https://gdpr-info.eu/
[4] https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95652381
[5] https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95652384
Re: [DISCUSSION] TDE. Phase-2. Master key rotation.
Posted by Nikolay Izhikov <ni...@apache.org>.
Hello, Igniters.
We had private discussion of this design with Anton Vinogradov, Vladimir Ozerov, Alexey Goncharyuk.
Design need to be improved in the following ways:
1. Clear recovery logic should be written.
2. Clear process of atomic cache keys and master key change should be written.
3. We should design master key rotation process in the way it would be easy to implement EncryptionSPI for some enterprise encryption provider(AWS Key Management Service as an example)
Which aspect of EncryptionSPI should be improved to make this process obvious.
В Ср, 24/10/2018 в 17:19 +0300, Nikolay Izhikov пишет:
> Hello.
>
> Deisgn updated [1]
>
> Please, share your feedback
>
> [1] https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95652381
>
>
> В Вт, 23/10/2018 в 21:49 +0300, Nikolay Izhikov пишет:
> > Hello, Anton.
> >
> > Thank you for your very usefull feedback!
> >
> > I accept your proposals.
> > Seems it makes this feature more robust and clear.
> >
> > Will update design in confluence in a couple of hours.
> >
> > В Вт, 23/10/2018 в 19:18 +0300, Anton Vinogradov пишет:
> > > Nikolay,
> > >
> > > I have some comments.
> > >
> > > 1) Master key setup and removal is a responsibility of system administrator.
> > > No matter how he will set a new master key or remove an old.
> > > The only need it to have both keys, new and old, installed before starting
> > > the rotation process.
> > >
> > > 2) Master Key rotation is a process of cache's keys re-encryption.
> > >
> > > So, we should send a message contains a new master key id only.
> > > We also have to check that "Master Key rotation" allowed to the user by
> > > checking it has SecurityPermission#ADMIN_OPS permission.
> > >
> > > During this message handling, we have to re-encrypt keys and to set new
> > > master key id.
> > >
> > > 3) We should provide recovery mode for nodes unexpectedly leaved cluster
> > > during "Master Key rotation" process.
> > > We have to have a special "node start" command allows to change node's
> > > master key before joining the cluster.
> > >
> > > пн, 22 окт. 2018 г. в 22:39, Nikolay Izhikov <ni...@apache.org>:
> > >
> > > > Hello, Igniters.
> > > >
> > > > As you may know, we successfully implement TDE. Phase-1 feature. [1]
> > > > This improvement allows users to use an encrypted cache.
> > > >
> > > > To make TDE production ready I propose to extend it with two things:
> > > >
> > > > * Master key rotation.
> > > > * Cache key rotation.
> > > >
> > > > Such features required by many security standards such as PCI DSS [2] and
> > > > GDPR [3]
> > > >
> > > > I think it would be easier to discuss, implement and review both features
> > > > separately.
> > > > So my plan is the following:
> > > >
> > > > * TDE. Phase-2 - Master key rotation [4]
> > > > * TDE. Phase-3 - Cache key rotation. [5]
> > > >
> > > > I prepared designs for both parts.
> > > > I want to specifically discuss Phase-2 design.
> > > > Phase-3 design state is [EARLY DRAFT].
> > > > I propose to use Phase-3 design as a reference to make sure we have a
> > > > consistent view of all aspects of TDE
> > > > and can be implemented without significant changes in earlier parts.
> > > >
> > > > Below, my design.
> > > > Following changes will be made in confluence [4].
> > > > Please, share your feedback.
> > > >
> > > > *TDE. PHASE-2. MASTER KEY ROTATION*
> > > > Key rotation required in case of it compromising or at the end of
> > > > crypto period(key validity period).
> > > >
> > > > Goal:
> > > > To implement the ability to rotate master encryption key.
> > > >
> > > > New processes:
> > > > 1. Master key rotation.
> > > > 2. Removal of a master key.
> > > >
> > > > New administrator commands:
> > > > 1. Master keys view: node -> master key hash
> > > > 2. Cache group keys view: node -> group name -> encryption key
> > > > hash
> > > >
> > > > MASTER KEY ROTATION:
> > > > Process start:
> > > > Administrator initiates key rotation via some kind of
> > > > user interface(CLI, Visor, Web Console, JMX, etc).
> > > >
> > > > Process description:
> > > > Message is sent by discovery.
> > > > A Message should contain:
> > > > * Master cache key encrypted with the current
> > > > master key.
> > > >
> > > > When server node processed message following actions are
> > > > executed:
> > > > * Blocks creation of encrypted cache key.
> > > > * Encrypt cache group keys with new master key.
> > > > * Unblock creation of encrypted cache key.
> > > >
> > > > New joining node should also change the current master key
> > > > with the new one.
> > > >
> > > > Process completion:
> > > > The administrator initiates process completion via the
> > > > interface by using “master key removal” command.
> > > > Design assumes an administrator will check that all nodes
> > > > successfully change master key and all required nodes are alive.
> > > >
> > > > MASTER KEY REMOVAL:
> > > > Process start:
> > > > Administrator initiates process via some kind of user
> > > > interface(CLI, Visor, WebConsole, JMX, etc),
> > > >
> > > > Process description:
> > > > Message is sent by discovery.
> > > > Message should contain:
> > > > * New master key hash.
> > > > When a server node processed message following actions are
> > > > executed:
> > > > Received master key hash compared with known master key
> > > > hash.
> > > > Previous master key removed using configured
> > > > EncryptionSPI.
> > > >
> > > > NEW COMMANDS:
> > > > Master key hashes.
> > > > Input: nothing
> > > > Output: List of Tuples3
> > > > * Node ID
> > > > * Current key hash
> > > > * Previous key hash or null.
> > > > Cache key hashes.
> > > > Input: cache id.
> > > > Output: List of Tuples3
> > > > * Node ID
> > > > * Current key hash
> > > > * Previous key hash or null.
> > > >
> > > > [1] https://issues.apache.org/jira/browse/IGNITE-8260
> > > > [2] https://www.pcisecuritystandards.org/documents/PCI_DSS_v3-2-1.pdf
> > > > [3] https://gdpr-info.eu/
> > > > [4]
> > > > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95652381
> > > > [5]
> > > > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95652384
> > > >
Re: [DISCUSSION] TDE. Phase-2. Master key rotation.
Posted by Nikolay Izhikov <ni...@apache.org>.
Hello.
Deisgn updated [1]
Please, share your feedback
[1] https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95652381
В Вт, 23/10/2018 в 21:49 +0300, Nikolay Izhikov пишет:
> Hello, Anton.
>
> Thank you for your very usefull feedback!
>
> I accept your proposals.
> Seems it makes this feature more robust and clear.
>
> Will update design in confluence in a couple of hours.
>
> В Вт, 23/10/2018 в 19:18 +0300, Anton Vinogradov пишет:
> > Nikolay,
> >
> > I have some comments.
> >
> > 1) Master key setup and removal is a responsibility of system administrator.
> > No matter how he will set a new master key or remove an old.
> > The only need it to have both keys, new and old, installed before starting
> > the rotation process.
> >
> > 2) Master Key rotation is a process of cache's keys re-encryption.
> >
> > So, we should send a message contains a new master key id only.
> > We also have to check that "Master Key rotation" allowed to the user by
> > checking it has SecurityPermission#ADMIN_OPS permission.
> >
> > During this message handling, we have to re-encrypt keys and to set new
> > master key id.
> >
> > 3) We should provide recovery mode for nodes unexpectedly leaved cluster
> > during "Master Key rotation" process.
> > We have to have a special "node start" command allows to change node's
> > master key before joining the cluster.
> >
> > пн, 22 окт. 2018 г. в 22:39, Nikolay Izhikov <ni...@apache.org>:
> >
> > > Hello, Igniters.
> > >
> > > As you may know, we successfully implement TDE. Phase-1 feature. [1]
> > > This improvement allows users to use an encrypted cache.
> > >
> > > To make TDE production ready I propose to extend it with two things:
> > >
> > > * Master key rotation.
> > > * Cache key rotation.
> > >
> > > Such features required by many security standards such as PCI DSS [2] and
> > > GDPR [3]
> > >
> > > I think it would be easier to discuss, implement and review both features
> > > separately.
> > > So my plan is the following:
> > >
> > > * TDE. Phase-2 - Master key rotation [4]
> > > * TDE. Phase-3 - Cache key rotation. [5]
> > >
> > > I prepared designs for both parts.
> > > I want to specifically discuss Phase-2 design.
> > > Phase-3 design state is [EARLY DRAFT].
> > > I propose to use Phase-3 design as a reference to make sure we have a
> > > consistent view of all aspects of TDE
> > > and can be implemented without significant changes in earlier parts.
> > >
> > > Below, my design.
> > > Following changes will be made in confluence [4].
> > > Please, share your feedback.
> > >
> > > *TDE. PHASE-2. MASTER KEY ROTATION*
> > > Key rotation required in case of it compromising or at the end of
> > > crypto period(key validity period).
> > >
> > > Goal:
> > > To implement the ability to rotate master encryption key.
> > >
> > > New processes:
> > > 1. Master key rotation.
> > > 2. Removal of a master key.
> > >
> > > New administrator commands:
> > > 1. Master keys view: node -> master key hash
> > > 2. Cache group keys view: node -> group name -> encryption key
> > > hash
> > >
> > > MASTER KEY ROTATION:
> > > Process start:
> > > Administrator initiates key rotation via some kind of
> > > user interface(CLI, Visor, Web Console, JMX, etc).
> > >
> > > Process description:
> > > Message is sent by discovery.
> > > A Message should contain:
> > > * Master cache key encrypted with the current
> > > master key.
> > >
> > > When server node processed message following actions are
> > > executed:
> > > * Blocks creation of encrypted cache key.
> > > * Encrypt cache group keys with new master key.
> > > * Unblock creation of encrypted cache key.
> > >
> > > New joining node should also change the current master key
> > > with the new one.
> > >
> > > Process completion:
> > > The administrator initiates process completion via the
> > > interface by using “master key removal” command.
> > > Design assumes an administrator will check that all nodes
> > > successfully change master key and all required nodes are alive.
> > >
> > > MASTER KEY REMOVAL:
> > > Process start:
> > > Administrator initiates process via some kind of user
> > > interface(CLI, Visor, WebConsole, JMX, etc),
> > >
> > > Process description:
> > > Message is sent by discovery.
> > > Message should contain:
> > > * New master key hash.
> > > When a server node processed message following actions are
> > > executed:
> > > Received master key hash compared with known master key
> > > hash.
> > > Previous master key removed using configured
> > > EncryptionSPI.
> > >
> > > NEW COMMANDS:
> > > Master key hashes.
> > > Input: nothing
> > > Output: List of Tuples3
> > > * Node ID
> > > * Current key hash
> > > * Previous key hash or null.
> > > Cache key hashes.
> > > Input: cache id.
> > > Output: List of Tuples3
> > > * Node ID
> > > * Current key hash
> > > * Previous key hash or null.
> > >
> > > [1] https://issues.apache.org/jira/browse/IGNITE-8260
> > > [2] https://www.pcisecuritystandards.org/documents/PCI_DSS_v3-2-1.pdf
> > > [3] https://gdpr-info.eu/
> > > [4]
> > > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95652381
> > > [5]
> > > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95652384
> > >
Re: [DISCUSSION] TDE. Phase-2. Master key rotation.
Posted by Nikolay Izhikov <ni...@apache.org>.
Hello, Anton.
Thank you for your very usefull feedback!
I accept your proposals.
Seems it makes this feature more robust and clear.
Will update design in confluence in a couple of hours.
В Вт, 23/10/2018 в 19:18 +0300, Anton Vinogradov пишет:
> Nikolay,
>
> I have some comments.
>
> 1) Master key setup and removal is a responsibility of system administrator.
> No matter how he will set a new master key or remove an old.
> The only need it to have both keys, new and old, installed before starting
> the rotation process.
>
> 2) Master Key rotation is a process of cache's keys re-encryption.
>
> So, we should send a message contains a new master key id only.
> We also have to check that "Master Key rotation" allowed to the user by
> checking it has SecurityPermission#ADMIN_OPS permission.
>
> During this message handling, we have to re-encrypt keys and to set new
> master key id.
>
> 3) We should provide recovery mode for nodes unexpectedly leaved cluster
> during "Master Key rotation" process.
> We have to have a special "node start" command allows to change node's
> master key before joining the cluster.
>
> пн, 22 окт. 2018 г. в 22:39, Nikolay Izhikov <ni...@apache.org>:
>
> > Hello, Igniters.
> >
> > As you may know, we successfully implement TDE. Phase-1 feature. [1]
> > This improvement allows users to use an encrypted cache.
> >
> > To make TDE production ready I propose to extend it with two things:
> >
> > * Master key rotation.
> > * Cache key rotation.
> >
> > Such features required by many security standards such as PCI DSS [2] and
> > GDPR [3]
> >
> > I think it would be easier to discuss, implement and review both features
> > separately.
> > So my plan is the following:
> >
> > * TDE. Phase-2 - Master key rotation [4]
> > * TDE. Phase-3 - Cache key rotation. [5]
> >
> > I prepared designs for both parts.
> > I want to specifically discuss Phase-2 design.
> > Phase-3 design state is [EARLY DRAFT].
> > I propose to use Phase-3 design as a reference to make sure we have a
> > consistent view of all aspects of TDE
> > and can be implemented without significant changes in earlier parts.
> >
> > Below, my design.
> > Following changes will be made in confluence [4].
> > Please, share your feedback.
> >
> > *TDE. PHASE-2. MASTER KEY ROTATION*
> > Key rotation required in case of it compromising or at the end of
> > crypto period(key validity period).
> >
> > Goal:
> > To implement the ability to rotate master encryption key.
> >
> > New processes:
> > 1. Master key rotation.
> > 2. Removal of a master key.
> >
> > New administrator commands:
> > 1. Master keys view: node -> master key hash
> > 2. Cache group keys view: node -> group name -> encryption key
> > hash
> >
> > MASTER KEY ROTATION:
> > Process start:
> > Administrator initiates key rotation via some kind of
> > user interface(CLI, Visor, Web Console, JMX, etc).
> >
> > Process description:
> > Message is sent by discovery.
> > A Message should contain:
> > * Master cache key encrypted with the current
> > master key.
> >
> > When server node processed message following actions are
> > executed:
> > * Blocks creation of encrypted cache key.
> > * Encrypt cache group keys with new master key.
> > * Unblock creation of encrypted cache key.
> >
> > New joining node should also change the current master key
> > with the new one.
> >
> > Process completion:
> > The administrator initiates process completion via the
> > interface by using “master key removal” command.
> > Design assumes an administrator will check that all nodes
> > successfully change master key and all required nodes are alive.
> >
> > MASTER KEY REMOVAL:
> > Process start:
> > Administrator initiates process via some kind of user
> > interface(CLI, Visor, WebConsole, JMX, etc),
> >
> > Process description:
> > Message is sent by discovery.
> > Message should contain:
> > * New master key hash.
> > When a server node processed message following actions are
> > executed:
> > Received master key hash compared with known master key
> > hash.
> > Previous master key removed using configured
> > EncryptionSPI.
> >
> > NEW COMMANDS:
> > Master key hashes.
> > Input: nothing
> > Output: List of Tuples3
> > * Node ID
> > * Current key hash
> > * Previous key hash or null.
> > Cache key hashes.
> > Input: cache id.
> > Output: List of Tuples3
> > * Node ID
> > * Current key hash
> > * Previous key hash or null.
> >
> > [1] https://issues.apache.org/jira/browse/IGNITE-8260
> > [2] https://www.pcisecuritystandards.org/documents/PCI_DSS_v3-2-1.pdf
> > [3] https://gdpr-info.eu/
> > [4]
> > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95652381
> > [5]
> > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95652384
> >
Re: [DISCUSSION] TDE. Phase-2. Master key rotation.
Posted by Anton Vinogradov <av...@apache.org>.
Nikolay,
I have some comments.
1) Master key setup and removal is a responsibility of system administrator.
No matter how he will set a new master key or remove an old.
The only need it to have both keys, new and old, installed before starting
the rotation process.
2) Master Key rotation is a process of cache's keys re-encryption.
So, we should send a message contains a new master key id only.
We also have to check that "Master Key rotation" allowed to the user by
checking it has SecurityPermission#ADMIN_OPS permission.
During this message handling, we have to re-encrypt keys and to set new
master key id.
3) We should provide recovery mode for nodes unexpectedly leaved cluster
during "Master Key rotation" process.
We have to have a special "node start" command allows to change node's
master key before joining the cluster.
пн, 22 окт. 2018 г. в 22:39, Nikolay Izhikov <ni...@apache.org>:
> Hello, Igniters.
>
> As you may know, we successfully implement TDE. Phase-1 feature. [1]
> This improvement allows users to use an encrypted cache.
>
> To make TDE production ready I propose to extend it with two things:
>
> * Master key rotation.
> * Cache key rotation.
>
> Such features required by many security standards such as PCI DSS [2] and
> GDPR [3]
>
> I think it would be easier to discuss, implement and review both features
> separately.
> So my plan is the following:
>
> * TDE. Phase-2 - Master key rotation [4]
> * TDE. Phase-3 - Cache key rotation. [5]
>
> I prepared designs for both parts.
> I want to specifically discuss Phase-2 design.
> Phase-3 design state is [EARLY DRAFT].
> I propose to use Phase-3 design as a reference to make sure we have a
> consistent view of all aspects of TDE
> and can be implemented without significant changes in earlier parts.
>
> Below, my design.
> Following changes will be made in confluence [4].
> Please, share your feedback.
>
> *TDE. PHASE-2. MASTER KEY ROTATION*
> Key rotation required in case of it compromising or at the end of
> crypto period(key validity period).
>
> Goal:
> To implement the ability to rotate master encryption key.
>
> New processes:
> 1. Master key rotation.
> 2. Removal of a master key.
>
> New administrator commands:
> 1. Master keys view: node -> master key hash
> 2. Cache group keys view: node -> group name -> encryption key
> hash
>
> MASTER KEY ROTATION:
> Process start:
> Administrator initiates key rotation via some kind of
> user interface(CLI, Visor, Web Console, JMX, etc).
>
> Process description:
> Message is sent by discovery.
> A Message should contain:
> * Master cache key encrypted with the current
> master key.
>
> When server node processed message following actions are
> executed:
> * Blocks creation of encrypted cache key.
> * Encrypt cache group keys with new master key.
> * Unblock creation of encrypted cache key.
>
> New joining node should also change the current master key
> with the new one.
>
> Process completion:
> The administrator initiates process completion via the
> interface by using “master key removal” command.
> Design assumes an administrator will check that all nodes
> successfully change master key and all required nodes are alive.
>
> MASTER KEY REMOVAL:
> Process start:
> Administrator initiates process via some kind of user
> interface(CLI, Visor, WebConsole, JMX, etc),
>
> Process description:
> Message is sent by discovery.
> Message should contain:
> * New master key hash.
> When a server node processed message following actions are
> executed:
> Received master key hash compared with known master key
> hash.
> Previous master key removed using configured
> EncryptionSPI.
>
> NEW COMMANDS:
> Master key hashes.
> Input: nothing
> Output: List of Tuples3
> * Node ID
> * Current key hash
> * Previous key hash or null.
> Cache key hashes.
> Input: cache id.
> Output: List of Tuples3
> * Node ID
> * Current key hash
> * Previous key hash or null.
>
> [1] https://issues.apache.org/jira/browse/IGNITE-8260
> [2] https://www.pcisecuritystandards.org/documents/PCI_DSS_v3-2-1.pdf
> [3] https://gdpr-info.eu/
> [4]
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95652381
> [5]
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95652384
>