From user-return-16414-apmail-couchdb-user-archive=couchdb.apache.org@couchdb.apache.org Tue May 31 18:19:19 2011
Return-Path:
X-Original-To: apmail-couchdb-user-archive@www.apache.org
Delivered-To: apmail-couchdb-user-archive@www.apache.org
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
by minotaur.apache.org (Postfix) with SMTP id 0523B464A
for ; Tue, 31 May 2011 18:19:19 +0000 (UTC)
Received: (qmail 62259 invoked by uid 500); 31 May 2011 18:19:17 -0000
Delivered-To: apmail-couchdb-user-archive@couchdb.apache.org
Received: (qmail 62220 invoked by uid 500); 31 May 2011 18:19:17 -0000
Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
List-Help:
List-Unsubscribe:
List-Post:
List-Id:
Reply-To: user@couchdb.apache.org
Delivered-To: mailing list user@couchdb.apache.org
Received: (qmail 62212 invoked by uid 99); 31 May 2011 18:19:17 -0000
Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230)
by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 31 May 2011 18:19:17 +0000
X-ASF-Spam-Status: No, hits=4.0 required=5.0
tests=FREEMAIL_FROM,FREEMAIL_REPLY,HTML_MESSAGE,RCVD_IN_DNSWL_LOW,RFC_ABUSE_POST,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL
X-Spam-Check-By: apache.org
Received-SPF: pass (nike.apache.org: domain of jasonlanexml@googlemail.com designates 209.85.160.52 as permitted sender)
Received: from [209.85.160.52] (HELO mail-pw0-f52.google.com) (209.85.160.52)
by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 31 May 2011 18:19:10 +0000
Received: by pwi4 with SMTP id 4so2882973pwi.11
for ; Tue, 31 May 2011 11:18:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=googlemail.com; s=gamma;
h=domainkey-signature:mime-version:in-reply-to:references:date
:message-id:subject:from:to:content-type;
bh=J3x7Oh++6/j9TWo76NLF6lRemmLfa+znmKo/a4GpJSs=;
b=W2xAHqsPgC+4MHzEYRra5PIJtZy1wE48ujZv10lHBXFfcXF3cA+swTf4CCIK7sKTLS
rhMeAMhIrC26ONoKwIVxHpoe09fnhoHQzCQZUR2FncEZVOsQrIWzc1UYA7joQ0BrA5zm
NofsqW3Zr/8JyUtTLMG2ZasRibDAv/FgPf4bE=
DomainKey-Signature: a=rsa-sha1; c=nofws;
d=googlemail.com; s=gamma;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:content-type;
b=IqV3ISWWUBS/B57BqVhRP0rZ//SzLj5YbfE93T1Y707i5dplW69ddL2UG+nXk9WEu1
WpYWjkTGuh4mskwiJTglX7Oa3Faja962TD6ecBbJnN1I5kGmNOkGrdaJN3oTAx8fShPE
v80/WQADhzfO+D+iSxwog93KZIfXLbms/63s0=
MIME-Version: 1.0
Received: by 10.68.69.105 with SMTP id d9mr2360096pbu.455.1306865928715; Tue,
31 May 2011 11:18:48 -0700 (PDT)
Received: by 10.142.226.18 with HTTP; Tue, 31 May 2011 11:18:43 -0700 (PDT)
Received: by 10.142.226.18 with HTTP; Tue, 31 May 2011 11:18:43 -0700 (PDT)
In-Reply-To:
References: <2BF12A23-EC9B-4E43-A154-07FCF325804C@me.com>
Date: Tue, 31 May 2011 19:18:43 +0100
Message-ID:
Subject: Re: Encryption Library for data transfer between clients and CouchDB
: a requirement in healthcare app.
From: Jason Lane
To: user@couchdb.apache.org
Content-Type: multipart/alternative; boundary=0015174be502733f6e04a4966f45
X-Virus-Checked: Checked by ClamAV on apache.org
--0015174be502733f6e04a4966f45
Content-Type: text/plain; charset=ISO-8859-1
Look at nodejs. Crypto functions are part of core features :)
sent from my Nexus S
On May 31, 2011 2:25 PM, "arnaudbos" wrote:
> writes:
>
>>
>> Hi!
>>
>> We are about to release our first version of an EHR (Electronic
Healthcare
> Record) build on CouchDB. Now is
>> time for us to deal in more details with data security issues in order to
> protect patient data,
>> particularly with data encryption on the net and signed documents. We
think
> about two ways and are willing
>> to combine both when appropriate:
>> - using https (of course);
>> - using encryption and documents signing with PGP public/private keys;
>> - both may be used for health data.
>>
>> We have read about similar questions on couchdb-user-archive (e.g.
"Proposal
> For Storing Signatures In
>> JSON" including the article and cononical-json from Chris in the Couchdb
Wiki,
> or the post "Building
>> Erlang app around CouchDB" which stated on Apr 21, 2009 "Common features
such
> as authentication,
>> authorization, caching, compression, partitioning, proxying, tunneling,
> encryption or URI
>> rewriting are possible by placing standard applications such as Apache
httpd
> or nginx in front of your
>> server.") but most posts are 1+ year old. Did I miss a current roadmap of
> CouchDb on this topic?
>>
>> In our case we need encryption on the client part and the server. We have
all
> the javascript code to build a
>> library using PGP. Also, keys generation on the browser client appears
fast
> enough for 1024-bits keys (<5
>> secs) and subsequent encryption of docs takes only a few millisecs. Our
> current idea is exposed
>> thereafter. We would welcome CouchDB Guru's advices and comments.
>>
>> The principle we intend to implement is that both communication parties
(local
> and remote) generate their
>> own private/public session keys and send their public key to the other
party.
> Then, during the session any
>> data can be transfered encrypted and automatically decoded by the
receiver. We
> are writing a javascript
>> library for a sort of encryption tunnel for communicating between clients
and
> CouchDB. We instanciate a
>> Security object (which privately generates and wraps the local private
key for
> the session) and then
>> exposes the following functions :
>> - setRemotePublicKey(remotePublicKey) : to be called at most one time.
>> - getPublicKey() : returns the local public key.
>> - encode(content) : returns the PGP message of a content string encoded
with
> the remotePublicKey.
>> - decode(pgpMsg) : returns the decoded string of a PGP message which was
> encoded with the local public key (getPublicKey()).
>> - signDoc(couchDocument) : to add a digital signature to a document (the
> signature is only valid for the
>> session, so more to design here).
>>
>> The workflow is the following. Given S a remote instance of Security on
the
> CouchDB Server and C the local
>> instance of Security on the web Client. The lifetime C is the session,
maybe
> same for S. Only public keys
>> travel the net and then encrypted data. The steps are as follows:
>>
>> 1. local : C = new Security();
>> 2. local : send cPubKey = C.getPublicKey()
>> 3a. remote : receive cPubKey and execute S = new Security(cPubKey);
>> 3b. remote : now the remote is able to receive data encrypted by
> C.encode(content)
>> 3c. remote : decode encrypted data by local with S.decode(data)
>> 4. remote : send sPubKey = S.getPublicKey()
>> 5. local : receive sPubKey and execute C.setRemotePublicKey(sPubKey);
>> 5b. local : now local client can receive data encoded by remote party
with
> S.encode(content)
>> 5c. local : decode remote data with C.decode(data)
>>
>> Alternate workflow : both local and remote instanciate simultaneously
their
> new Security() and send
>> their getPublicKey(), when received, both execute the
setRemotePublicKey()
> appropriately. The
>> normal sequence seems to be more natural since it allows the web client
to
> generate its local public key and
>> send it to the remote server which create its Security and returns its
own
> public key as a result. Then, both
>> parties know how to communicate. One problem could arise if other async
> requests are pending: will they be
>> encrypted or not? One way to answer is to admit that both crypted and
> unencrypted data can be exchanged and
>> will be recognized on either the header of the response, or the
'-----BEGIN
> PGP MESSAGE-----'.
>>
>> Even better : integrating the security on the session creation when a
client
> request CouchDB. The
>> CouchDB's gurus could explain if CouchDB could generate its Security
instance
> on login or session
>> initialization (config.httpd_global_handlers? config.couch_httpd_auth?)
and
> add it to the session
>> object (e.g. session.security = {pubkey:'...', ...}). Could we get this
> security feature as a standard
>> or an optional plugin in CouchDB? We are ready to share our security
library
> and help the feature work. And
>> it would be fine that the public key of the client browser be sent with
> encrypted login data (which means
>> that CouchDB send its public key before client login).
>>
>> Before going too far in developing such a security library, we would like
to
> know if there are alternate ways
>> to deal with security and data encryption (+document signing) between the
web
> client and CouchDB. We are
>> aware that in order to make this library transparent to users and devs we
> should hook our library inside
>> CouchDB in order that the data received from the client is decoded
> appropriately (at some
>> 'beforeProcess' event in CouchDB) and encoded before sending data to the
> client (afterProcess event or
>> beforeSending). Minor update of the CouchDB Ajax code will make the
> encoding/decoding fully
>> transparent on client's side.
>>
>> More has to be designed for using certificates to be used independantly
of the
> session duration. But the
>> principles will be the same, just the way we generate or acquired a valid
> certificate (i.e. the
>> public/private keys) will have to change.
>>
>> Any comment welcome!
>> Thanks,
>> Joel
>>
>>
>
>
> Hi,
>
> I'm starting to work on a CouchDB based EMR for my MSc Dissertation
project and
> I'm very interested about the security questions and your work in general.
>
> Sorry I can't answer your questions but I would really really be
interested in
> talking about your project which could help me greatly.
>
> I have so many questions :D
> Don't hesitate to join me please, I give my address so it's easier to
talk:
> arnaud.tlse@gmail.com
>
> Cheers,
> Arnaud.
>
--0015174be502733f6e04a4966f45--