Support encrypted client data

[trevorcarlson]

One idea could be to improve the security of the data on the client itself, in case it was stolen, etc. We could do this by using a public-private keypair, where all of the data would be stored encrypted locally. Only when the data was sent back to the server would it be decrypted and stored in the database (or optionally, not decrypted, and only decrypted by the end user). We could allow the users to maintain their own keypairs, as well as handle revocation, etc. If we did a full encryption setup, then we'd need to have the keys to be able to analyze the data for the users.

[transistorize]

Our privacy policy as it's written now stipulates that we do this already.

[trevorcarlson]

Bryan,

That sounds like we'll need to update it to remove that part until we have that implementation complete, right?

Trevor

On Apr 8, 2014, at 2:43 PM, Bryan Valentini [email protected] wrote:

Our privacy policy as it's written now stipulates that we do this already.

—
Reply to this email directly or view it on GitHub.

[transistorize]

The privacy policy has been out for review for several weeks and I received no feedback. Feel free to modify as you like. You could even check it into github wiki if you wanted.

[aohren]

Wouldn't encrypting data server side relegate us to a data storage locker?
What sort of analytics can we perform on encrypted data?

On Tue, Apr 8, 2014 at 2:48 PM, Bryan Valentini [email protected]:

The privacy policy has been out for review for several weeks and I
received no feedback. Feel free to modify as you like. You could even check
it into github wiki if you wanted.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/10#issuecomment-39886383
.

[trevorcarlson]

Adam,

My thought here was that we'd encrypt it on the client side, but then decrypt it as we receive it on the server. This is just an idea at this point, but makes sense if we want to support encrypted agents.

Trevor

On Apr 8, 2014, at 3:52 PM, Adam Ohren [email protected] wrote:

Wouldn't encrypting data server side relegate us to a data storage locker?
What sort of analytics can we perform on encrypted data?

On Tue, Apr 8, 2014 at 2:48 PM, Bryan Valentini [email protected]:

The privacy policy has been out for review for several weeks and I
received no feedback. Feel free to modify as you like. You could even check
it into github wiki if you wanted.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/10#issuecomment-39886383
.

—
Reply to this email directly or view it on GitHub.

[aohren]

Ah cool, gotcha.

On Tue, Apr 8, 2014 at 3:54 PM, trevorcarlson [email protected]:

Adam,

My thought here was that we'd encrypt it on the client side, but then
decrypt it as we receive it on the server. This is just an idea at this
point, but makes sense if we want to support encrypted agents.

Trevor

On Apr 8, 2014, at 3:52 PM, Adam Ohren [email protected] wrote:

Wouldn't encrypting data server side relegate us to a data storage
locker?
What sort of analytics can we perform on encrypted data?

On Tue, Apr 8, 2014 at 2:48 PM, Bryan Valentini <
[email protected]>wrote:

The privacy policy has been out for review for several weeks and I
received no feedback. Feel free to modify as you like. You could even
check
it into github wiki if you wanted.

—
Reply to this email directly or view it on GitHub<
https://github.com/kinisi/geoserver/issues/10#issuecomment-39886383>
.

—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/10#issuecomment-39894008
.

[aohren]

Though we already have encrypted the connection. I'm not sure what we're going to gain from encrypting the data again before sending it over an encrypted connection.

[trevorcarlson]

Adam,

 The gain, is the fact that the GPS data would all be on the client in an encrypted form. This is good for client security, because if they lost the device, they wouldn't have to worry about the data getting into someone else's hands. Encryption is for agent data storage, and SSL to the server is to protect the API key.

Trevor

On Apr 8, 2014, at 4:45 PM, Adam Ohren [email protected] wrote:

Though we already have encrypted the connection. I'm not sure what we're going to gain from encrypting the data again before sending it over an encrypted connection.

—
Reply to this email directly or view it on GitHub.

[aohren]

Agreed that make sense for persistent data on the device to be encrypted. I
thought though you're talking about re-encrypting the data before sending
it over the encrypted connection.

On Tue, Apr 8, 2014 at 4:55 PM, trevorcarlson [email protected]:

Adam,

The gain, is the fact that the GPS data would all be on the client in an
encrypted form. This is good for client security, because if they lost the
device, they wouldn't have to worry about the data getting into someone
else's hands. Encryption is for agent data storage, and SSL to the server
is to protect the API key.

Trevor

On Apr 8, 2014, at 4:45 PM, Adam Ohren [email protected]
wrote:

Though we already have encrypted the connection. I'm not sure what we're
going to gain from encrypting the data again before sending it over an
encrypted connection.

—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/10#issuecomment-39900713
.

[sajacy]

To be secure, the data on the device can be encrypted with a client's
public key, but the private key will need to reside on our server. So I
think we are forced to send secured data (and should probably still send
over SSL, to avoid leaking info in the HTTP headers) which the server will
decrypt. Does that make sense?

Jeffrey Yangappssavvy http://appssavvy.com/ | Director of Platform
Engineering 594 Broadway Suite 207 | New York, NY 10012P | 212.941.5759 C |
646.464.4277 @jeffreyayang http://www.twitter.com/jeffreyayang

On Tue, Apr 8, 2014 at 4:59 PM, Adam Ohren [email protected] wrote:

Agreed that make sense for persistent data on the device to be encrypted.
I
thought though you're talking about re-encrypting the data before sending
it over the encrypted connection.

On Tue, Apr 8, 2014 at 4:55 PM, trevorcarlson [email protected]:

Adam,

The gain, is the fact that the GPS data would all be on the client in an
encrypted form. This is good for client security, because if they lost
the
device, they wouldn't have to worry about the data getting into someone
else's hands. Encryption is for agent data storage, and SSL to the
server
is to protect the API key.

Trevor

On Apr 8, 2014, at 4:45 PM, Adam Ohren [email protected]
wrote:

Though we already have encrypted the connection. I'm not sure what
we're
going to gain from encrypting the data again before sending it over an
encrypted connection.

—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHub<
https://github.com/kinisi/geoserver/issues/10#issuecomment-39900713>
.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/10#issuecomment-39901128
.

[trevorcarlson]

Jeff,

 This is exactly what I was thinking.

Trevor

On Apr 9, 2014, at 10:17 AM, Jeffrey Yang [email protected] wrote:

To be secure, the data on the device can be encrypted with a client's
public key, but the private key will need to reside on our server. So I
think we are forced to send secured data (and should probably still send
over SSL, to avoid leaking info in the HTTP headers) which the server will
decrypt. Does that make sense?

Jeffrey Yangappssavvy http://appssavvy.com/ | Director of Platform
Engineering 594 Broadway Suite 207 | New York, NY 10012P | 212.941.5759 C |
646.464.4277 @jeffreyayang http://www.twitter.com/jeffreyayang

On Tue, Apr 8, 2014 at 4:59 PM, Adam Ohren [email protected] wrote:

Agreed that make sense for persistent data on the device to be encrypted.
I
thought though you're talking about re-encrypting the data before sending
it over the encrypted connection.

On Tue, Apr 8, 2014 at 4:55 PM, trevorcarlson [email protected]:

Adam,

The gain, is the fact that the GPS data would all be on the client in an
encrypted form. This is good for client security, because if they lost
the
device, they wouldn't have to worry about the data getting into someone
else's hands. Encryption is for agent data storage, and SSL to the
server
is to protect the API key.

Trevor

On Apr 8, 2014, at 4:45 PM, Adam Ohren [email protected]
wrote:

Though we already have encrypted the connection. I'm not sure what
we're
going to gain from encrypting the data again before sending it over an
encrypted connection.

—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHub<
https://github.com/kinisi/geoserver/issues/10#issuecomment-39900713>
.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/10#issuecomment-39901128
.

—
Reply to this email directly or view it on GitHub.

[aohren]

My concern is that this is moving us towards a more blackbox environment
and away from an open hackable kit-type solution; the device becomes pretty
much useless without the web service once we encrypt the data away.

Say for example a device's wifi/cell connection is broken and can't sync.
Now we can just pop out the SD card and read the data off of it. Or if
someone wants to use their own service; literally all the have to do is
point the agent code to a different URL. But they can't do this stuff if
the data's only readable by us.

So I guess the broader question is whether we're moving away from the
hackable DIY space and towards a closed service model.

On Wed, Apr 9, 2014 at 12:02 PM, trevorcarlson [email protected]:

Jeff,

This is exactly what I was thinking.

Trevor

On Apr 9, 2014, at 10:17 AM, Jeffrey Yang [email protected]
wrote:

To be secure, the data on the device can be encrypted with a client's
public key, but the private key will need to reside on our server. So I
think we are forced to send secured data (and should probably still send
over SSL, to avoid leaking info in the HTTP headers) which the server
will
decrypt. Does that make sense?

Jeffrey Yangappssavvy http://appssavvy.com/ | Director of Platform
Engineering 594 Broadway Suite 207 | New York, NY 10012P | 212.941.5759C |
646.464.4277 @jeffreyayang http://www.twitter.com/jeffreyayang

On Tue, Apr 8, 2014 at 4:59 PM, Adam Ohren [email protected]
wrote:

Agreed that make sense for persistent data on the device to be
encrypted.
I
thought though you're talking about re-encrypting the data before
sending
it over the encrypted connection.

On Tue, Apr 8, 2014 at 4:55 PM, trevorcarlson <
[email protected]>wrote:

Adam,

The gain, is the fact that the GPS data would all be on the client
in an
encrypted form. This is good for client security, because if they
lost
the
device, they wouldn't have to worry about the data getting into
someone
else's hands. Encryption is for agent data storage, and SSL to the
server
is to protect the API key.

Trevor

On Apr 8, 2014, at 4:45 PM, Adam Ohren [email protected]
wrote:

Though we already have encrypted the connection. I'm not sure what
we're
going to gain from encrypting the data again before sending it over
an
encrypted connection.

—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHub<
https://github.com/kinisi/geoserver/issues/10#issuecomment-39900713>
.

—
Reply to this email directly or view it on GitHub<
https://github.com/kinisi/geoserver/issues/10#issuecomment-39901128>
.

—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/10#issuecomment-39982056
.

[transistorize]

I too share your concern, Adam, and I don't want to move to a closed service model for the reasons you stated.

[aeratek]

I'll chime in from how the current PoC in CA views this topic, which is
that they don't need data encrypted on the agent (note I'm defining the
data collection software running on the Raspberry Pi as the "agent", and
the software running on a mobile app, desktop or web app as the "client").
They said that since the bus's data is, or one day will be, publicly
available, there is no need to protect it on the device. If the device is
stolen, all that's compromised is the publicly-available data (as well as
any token/key we have provisioned it).

So I'm assuming this same concept will be applicable for many more
customers in this space, since the agent data would feed in realtime via a
GTFS feed to a mobile app.

Now, as for other Use Cases, such as the consumer market or the school bus
Use Case in Maine, protecting this information (encrypting agent data) may
be more pressing as a feature. My instinct is to punt this problem
down-the-road and keep asking customers for their preference. But from a
technical implementation perspective, I like the idea of ironing-out a plan
like we're doing here.

On Wed, Apr 9, 2014 at 1:54 PM, Bryan Valentini [email protected]:

I too share your concern, Adam, and I don't want to move to a closed
service model for the reasons you stated.

Reply to this email directly or view it on GitHubhttps://github.com//issues/10#issuecomment-39995409
.