No, I did mean both client-side encryption and client-side decryption. If the admins cannot be trusted, then this seems like the only safe implementation. Never let that untrusted server have the plaintext or the key.
-- Mike On 23 Apr 2012, at 14:42 , Florentine, George wrote: > Mike, see my comments below. > > > thx, > > g > > > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of Michael Blakeley > Sent: Monday, April 23, 2012 1:56 PM > To: MarkLogic Developer Discussion > Subject: Re: [MarkLogic Dev General] ML Data Encryption > > Interesting approach. Wouldn't you have to encrypt and decrypt that data on > the client only? > >>>> Define client. In most multi-tier applications, there is business logic >>>> that needs to manipulate the decrypted data - I think doing it on the >>>> client would in general break the shearing architecture layers of >>>> presentation/business logic/storage that many apps use. > > Otherwise those sysadmins can see it in process memory. >>>> Good point. You still face a threat of sysadmins using process examiner >>>> tools to grab data. > > If the data is ever swapped to disk, it is exposed that way too. >>>> Also a good point.. > > Then there is the network. I presume you would use SSL, but if those > encrypted packets contain important plaintext data, that sounds like a very > strong incentive for someone to capture packets and work on cracking the SSL > encryption. It sounds like they might get your shared secret too, which might > be useful if the same shared key turns up in multiple applications. >>>> In the security audits I've been a part of, the risk of cracking SSL has >>>> been deemed less of a risk than sysadmins trolling file systems for >>>> unencrypted data. But there is risk in both places; the trick is in >>>> assessing the risk vs. the cost of mitigating the risk. > > Also, aren't those RDBMs products using triggers and views to implement the > feature? If so, a DBA with appropriate permissions can subvert the system. > For example, one could substitute a trigger that also copies the plaintext > data to a second location, for later perusal. >>>> Typically in field level encryption the data is protected by some >>>> encryption scheme that is backed into the database server (i.e. not in a >>>> trigger or view). To decrypt it, code has to provide a mechanism that the >>>> encryption mechanism recognizes and supports (digital cert, password, >>>> etc.) So subverting a view or trigger doesn't bypass the encryption - the >>>> threat is that someone gets access to the secret used for decrypting the >>>> data. > > So I think I prefer storage-level encryption, but if I had to do field-level > I would do the encryption on the client and never even tell the server about > it. >>>> I assume you meant to say "decryption" in the phrase above. I think the >>>> weakest link in field level encryption is protecting the secret that is >>>> used to decrypt the data. I've never seen anyone do client side field >>>> level decryption - not to say you couldn't do it, but all the ones I've >>>> seen have done the decryption in the business logic layer. > > -- Mike > > On 23 Apr 2012, at 11:50 , Florentine, George wrote: > >> Hey, Jason. You're right in that folks that care about encryption sometimes >> provide that capability in file storage. We see that with some of the >> customers we're working with. The problem with that approach is that from a >> threat assessment perspective, you've still got a fair amount of exposure to >> who can access the data if you put the encryption in the file system, >> specifically sysadmins that have access to the server that's hosting the xml >> database or any piece of code that can access the database. To eliminate >> those kinds of threats, folks in the relational database world have >> introduced the notion of field level encryption into their products. It can >> be a PITA, because it can introduce some tight coupling between your data >> and your application (the app needs to provide some sort of secret or shared >> secret in order to decrypt the data) but it does reduce the possible attack >> points to your data. >> >> I'd be curious if other folks have seen interest in providing encryption >> directly in ML. >> >> thx, >> >> g >> >> >> George Florentine >> >> VP, Engineering >> >> +1 (303) 542-2173 | Office >> +1 (303) 669-8628 | Cell >> +1 (303) 544-0522 | Fax >> >> [email protected] >> >> http://www.flatironssolutions.com >> >> >> >> >> >> >> >> >> >> -----Original Message----- >> From: [email protected] >> [mailto:[email protected]] On Behalf Of Jason Hunter >> Sent: Monday, April 23, 2012 12:08 PM >> To: MarkLogic Developer Discussion >> Subject: Re: [MarkLogic Dev General] ML Data Encryption >> >> No, people who care about that use encrypted filesystems. >> >> -jh- >> >> On Apr 23, 2012, at 10:30 AM, Danny Sinang wrote: >> >>> Hello, >>> >>> I know ML compresses data when storing it on disk. >>> >>> But does it also encrypt it ? >>> >>> Regards, >>> Danny >>> >>> >>> _______________________________________________ >>> General mailing list >>> [email protected] >>> http://developer.marklogic.com/mailman/listinfo/general >> >> _______________________________________________ >> General mailing list >> [email protected] >> http://developer.marklogic.com/mailman/listinfo/general >> _______________________________________________ >> General mailing list >> [email protected] >> http://developer.marklogic.com/mailman/listinfo/general >> > > _______________________________________________ > General mailing list > [email protected] > http://developer.marklogic.com/mailman/listinfo/general > _______________________________________________ > General mailing list > [email protected] > http://developer.marklogic.com/mailman/listinfo/general > _______________________________________________ General mailing list [email protected] http://developer.marklogic.com/mailman/listinfo/general
