[
https://issues.apache.org/jira/browse/HBASE-9578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13786122#comment-13786122
]
Andrew Purtell commented on HBASE-9578:
---------------------------------------
Hi Larry, if you are interested in discussing encryption options in/for the
HBase REST gateway, it's probably best to open another JIRA. Sounds like you
are contemplating having the client send plaintext to the REST server and then
REST acting further on behalf of the client. That's not the use case here, but
it could be useful for other ones.
Having private keys available on the server side - REST in this case - is
considered dangerous because compromise of a common location that aggregates
user activity can be used to collect private key material. The keys used to
encrypt the value data at the client should stay on the client and encryption
and decryption should happen there. It's also worth thinking what can be done
on the server, but the server side (including REST) remains untrusted and
should not be able to actually decrypt data. Given this kind of approach, REST
would need no modifications or further considerations, it would just pass
through value data already encrypted by the client and .
It's true that every client could run a REST gateway, but that would not be
common I suspect, people generally would deploy it in a gateway type
architecture.
> Client side cell encryption
> ---------------------------
>
> Key: HBASE-9578
> URL: https://issues.apache.org/jira/browse/HBASE-9578
> Project: HBase
> Issue Type: New Feature
> Reporter: Andrew Purtell
>
> HBASE-7544 will protect key and value data on the server from accidental
> leakage by way of improperly disposed disks, improper direct filesystem
> access, or incorrect HDFS permissions. There are also use cases where
> sensitive data stored in a table or column family by a given user or
> application should be protected from all others, and the combination of
> transparent server-side storage encryption and transport security (SASL
> auth-conf) is still not sufficient. These instances call for a client side
> per-cell encryption feature, given the following additional observations:
> - The scope of transmission, distribution, and storage of private key
> material should be as limited as possible. The server is a centralized target
> (even in the case of an HBase cluster) where the scope of damage from a
> compromise is magnified if user key material also resides there or can be
> intercepted after compromise. Where keys are stored in hardware devices, e.g.
> smartcards, getting the keys to the server may be not possible anyway.
> - A client system is far more likely than a contended shared server resource
> to have necessary available CPU cycles for per-operation cryptographic
> overheads.
> For some cases we might not care so much about the second item, but the first
> is very important.
> I have an implementation of per cell client side encryption as an encrypting
> HTable wrapper which I could contribute if there is interest.
> This JIRA is also about brainstorming how to do better than that.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
