From dev-return-33182-archive-asf-public=cust-asf.ponee.io@ignite.apache.org Tue Apr 10 16:30:20 2018 Return-Path: X-Original-To: archive-asf-public@cust-asf.ponee.io Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by mx-eu-01.ponee.io (Postfix) with SMTP id CDEF418064C for ; Tue, 10 Apr 2018 16:30:19 +0200 (CEST) Received: (qmail 15541 invoked by uid 500); 10 Apr 2018 14:30:18 -0000 Mailing-List: contact dev-help@ignite.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@ignite.apache.org Delivered-To: mailing list dev@ignite.apache.org Received: (qmail 15511 invoked by uid 99); 10 Apr 2018 14:30:18 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd4-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 10 Apr 2018 14:30:18 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd4-us-west.apache.org (ASF Mail Server at spamd4-us-west.apache.org) with ESMTP id A5901C030C for ; Tue, 10 Apr 2018 14:30:17 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd4-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 3.311 X-Spam-Level: *** X-Spam-Status: No, score=3.311 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=2, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URI_HEX=1.313] autolearn=disabled Authentication-Results: spamd4-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=gridgain-com.20150623.gappssmtp.com Received: from mx1-lw-eu.apache.org ([10.40.0.8]) by localhost (spamd4-us-west.apache.org [10.40.0.11]) (amavisd-new, port 10024) with ESMTP id NRqQ2cgPUr-n for ; Tue, 10 Apr 2018 14:30:14 +0000 (UTC) Received: from mail-ua0-f182.google.com (mail-ua0-f182.google.com [209.85.217.182]) by mx1-lw-eu.apache.org (ASF Mail Server at mx1-lw-eu.apache.org) with ESMTPS id BC4E55F24C for ; Tue, 10 Apr 2018 14:30:13 +0000 (UTC) Received: by mail-ua0-f182.google.com with SMTP id a17so7450962uaf.13 for ; Tue, 10 Apr 2018 07:30:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gridgain-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=iLvb8AXqILIFo1KnaUgEgiZxjhcZTlbJyaZLs8yyTh8=; b=M8QnPhyc4Nw46ACd8LwcbdYBHSY84hfWy54PI+Sjp3He6t0jILMwgRAQ5KL+Pkmurn KyoYC9uikEQGjX/xJFAiW0Nkk/t1Fii/dZelECLQVOdX8yJ/R8nRx+xgoj+qS97m0tV+ IHteuNkRVQOMWBEchhovyjSqigKJu+Icu9OqAZJDn8alSlE4qOHsLyWZ+stwxP0EaWCm 7m/5urQXa/6QeWDBLpFRl4L2FS8+GdKhNjzYyQC/dxUDuDg383kTV6MyfCBHIj51yToM a8Yp1uMrxb5eEQgOhIivInOMoXwZA860NwOn3/Y8BBXSasdN/ft1fsuO87rk/7PofVns y/kw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=iLvb8AXqILIFo1KnaUgEgiZxjhcZTlbJyaZLs8yyTh8=; b=em6M5p28cM+6HgZiAqANRZA5FQn33lC95LJlkYI5TQfKkaQVrHepbi4ytHSo53Bafc tFDqG7qm1XBAfuZUYYq5dsGoPB6JqueZ/uoXxj+T/Tff1F0zONhrcQgjhwqd5XBB6Ovg yMMgkcfiaFOr/7bj61f9/Fo2CxcUgPlkilzXgPTiT04ZUsKNhwOlPhTGRLKn9xOWL72s XX1fndFKaJ36qO0zCqbMv9QLHLKOjuM/rXnlFryCzkfLMoSpwNA/ymDa9zNaLdzmtTdu 20fpVrbkWePbiRE9LddKt+iUhkcXC94dGPWyvUl87GNLrp1yD0KokiSwj1YL2KuJsV+D k4Kw== X-Gm-Message-State: ALQs6tA8fce8nVAkakH/AmPi0DOxMOtse0mcUDalH8wMLvHFBdhPVGvw 8xADyTmYvVnfd7NSgewbt6O/kb2gKAV+zaAFA4JwwqCz X-Google-Smtp-Source: AIpwx49wPbu70AxUKabDs8HnYfP656Qq76axHt0dHyUwlCo6h9mLC2loGysDCGbuMgYcwts5G45x6Zp+66V+GiE2JFg= X-Received: by 10.176.35.198 with SMTP id c6mr506444uan.83.1523370607234; Tue, 10 Apr 2018 07:30:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.41.100 with HTTP; Tue, 10 Apr 2018 07:30:06 -0700 (PDT) In-Reply-To: <1523284927.14835.45.camel@gmail.com> References: <1522954892.28175.12.camel@gmail.com> <1523284927.14835.45.camel@gmail.com> From: Vladimir Ozerov Date: Tue, 10 Apr 2018 17:30:06 +0300 Message-ID: Subject: Re: IEP-18: Transparent Data Encryption To: Nikolay Izhikov Cc: dev Content-Type: multipart/alternative; boundary="f4f5e808be30e7ed1305697f5b2d" --f4f5e808be30e7ed1305697f5b2d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi NIkolay, Regarding system caches, rule of thumb here - do not use them. Keys should be stored near cache. As far as password: 1) Oracle auto-login wallet [1] 2) MySQL- password may be set inside configuration [2] I do not think that any kind of prompts are needed here out of the box. May be we could consider them in future, but at the moment it looks redundant to me. [1] https://docs.oracle.com/cd/E11882_01/network.112/e40393/asotrans.htm#CHDCCH= BH [2] https://dev.mysql.com/doc/refman/5.7/en/keyring-encrypted-file-plugin.html On Mon, Apr 9, 2018 at 5:42 PM, Nikolay Izhikov wrote= : > Hello, Vladimir. > > > 1) Why do you propose to store CEK in separate cache? > > All CEKs data should be available on all cluster nodes. > We want to use system cache to get data synchronization feature "for free= ". > > > We consider storing any metadata in system caches as antipattern from > our previous experience. > > Very interesting! > Can you share your experience? > I didn't know that. > I think we can use any convinient storage for CEK. > Current design doesn't couple to system caches, so we can change this par= t > at any moment. > > > 2) I do not think that decryption process should require any > "administrator" role and passwords. > > Instead, we can have a kind of pluggable interface which will provide > decrypted MEK on demand when it is needed. > > This should be pre-configured in advance on server node(s). > > AFAIK this is how a number of other vendors work. > > Can't agree with you, for now. > Can you please send me some info about implementation you refer to? > We study following papers to make current design: > > 1. ORACLE [1] > > To enable encryption one has to execute following statement: > > `ALTER SYSTEM SET ENCRYPTION KEY IDENTIFIED BY *clear_text_password*` > Or after database server restart - `ALTER SYSTEM SET WALLET OPEN > IDENTIFIED BY *clear_text_password*` > So yes, administrator is involved into server restart. > And no, it's not all automatic. > > 2. MSSQL [4] - AFAIK uses some Windows OS internal key storage to write > and read master key. > DB server process should have administrator(system) priveleges to access > that storage. > > > Instead, we can have a kind of pluggable interface which will provide > decrypted MEK on demand when it is needed. > > We, for sure, will have pluggable interface for providing MEK. > But, from my point of view, default implementation should use some defaul= t > java features. > I think we should use java key store. > It requires to have a clear text password to be loaded [3] > > [1] https://docs.oracle.com/cd/B19306_01/network.102/b14268/ > asotrans.htm#BABJJAIG > [2] https://technet.microsoft.com/en-us/library/bb934049(v=3Dsql.110).asp= x > [3] https://docs.oracle.com/javase/8/docs/api/java/ > security/KeyStore.html#load-java.io.InputStream-char:A- > [4] https://technet.microsoft.com/en-us/library/bb934049(v=3Dsql.110).asp= x > > > 3) CEK decryption should not be tied to MEK decryption. > > MEK will be available from the moment it obtained to the node stop. > So, we can decrypt existing or encrypt newly created CEK whenever it > necessary. > > > 4) I do not think that SSL should be a strict requirement. It is up to > the> user to asses the risks. > > I'm fully OK with it. > Let's remove that restriction. > > =D0=92 =D0=9F=D0=BD, 09/04/2018 =D0=B2 11:35 +0300, Vladimir Ozerov =D0= =BF=D0=B8=D1=88=D0=B5=D1=82: > > Hi Nikolay, > > > > First of all thank you for excellent summary. Two-tiered key management > is > > well respected technique and makes perfect sense to me. However, severa= l > > questions regarding architecture arises: > > > 3) CEK decryption should not be tied to MEK decryption. Main reason - C= EK > > could be required during dynamic cache/table creation. So there should = be > > no coupling between activation and CEK processing. > > > 4) I do not think that SSL should be a strict requirement. It is up to > the > > user to asses the risks. > > > > On Fri, Apr 6, 2018 at 9:59 PM, Denis Magda wrote: > > > > > Nikolay, Dmitriy R., > > > > > > Thanks for the research and for writing down a summary in the IEP for= m. > > > > > > Please answer several high-level questions: > > > > > > - Is it necessary to have CEP keys for every cache? Not sure how > all the > > > keys will be managed if the user wants to encrypt 10-100 caches. I= s > it > > > possible to use a single CEP by default with an option of having a > > > unique > > > one for a cache with more sensitive information? > > > - It's not written, but I guess it would be up to me which caches = to > > > encrypt, right? In practice, you don't need to have all the data > > > encrypted. > > > Usually, companies look to hide personal, payments history, etc. > > > - Should we think of procedures of CEP keys regeneration? A key ca= n > be > > > lost or stolen. > > > - Similar question goes for MEP key. > > > > > > -- > > > Denis > > > > > > On Thu, Apr 5, 2018 at 2:15 PM, Dmitriy Setrakyan < > dsetrakyan@apache.org> > > > wrote: > > > > > > > Here is a correct link to IEP: > > > > https://cwiki.apache.org/confluence/display/IGNITE/IEP- > > > > 18%3A+Transparent+Data+Encryption > > > > > > > > On Thu, Apr 5, 2018 at 12:01 PM, Nikolay Izhikov < > nizhikov@apache.org> > > > > wrote: > > > > > > > > > Hello, Igniters. > > > > > > > > > > Based on previous discussion [1] we've created "IEP-18: Transpare= nt > > > > > > Data > > > > > Encryption" [2] > > > > > I've planned to start implementation of TDE in few weeks. > > > > > I will create JIRA ticket for each piece of implementation. > > > > > > > > > > So, please, see IEP-18 and give us feedback. > > > > > > > > > > Dima Ryabov, huge thanks for pushing TDE IEP forward. > > > > > > > > > > [1] http://apache-ignite-developers.2346864.n4.nabble. > > > > > com/Transparent-Data-Encryption-TDE-in-Apache-Ignite-td18957.html > > > > > [2] https://cwiki.apache.org/confluence/pages/viewpage. > > > > > action?pageId=3D75979078 > > > > > > --f4f5e808be30e7ed1305697f5b2d--