[tor-talk] Could Tor be used for health informatics?

[Paul Syverson]

On Mon, May 30, 2016 at 09:18:48PM -0400, Nathan Freitas wrote:
> On Mon, May 30, 2016, at 09:08 PM, Seth David Schoen wrote:
> > Paul Templeton writes:
> > 
> > > Where Tor may fit...
> > > 
> > > The Tor network would provide the secure transport - each site would create an onion address. Central servers would keep tab of address and public keys for each site and practitioner.
> > 
> > I'm not convinced this is a good tradeoff for this application.  The
> > crypto in the current version of hidden services is weaker in several
> > respects than what you would get from an ordinary HTTPS connection.
> > These users probably don't need (or want?) location anonymity for either
> > side of the connection and may not appreciate the extra latency and
> > possible occasional reachability problems associated with the hidden
> > service connection.
> > 
> 
> I think the benefit of being able to run Onion services deep within a
> firewalled network without exposing public Internet IPs is an
> operational security value that outweighs the strength of the crypto. 

It's not a mutually exclusive situation. Cf. "Bake in .onion for
Tear-Free and Stronger Website Authentication" IEEE Security & Privacy
14(2), March/April 2016.

Most relevantly, from the last section.

  First, currently deployed onion addresses and protocols rely on
  SHA-1 and RSA-1024, both of which have reached the end of their
  effective-security lifetimes. But Tor client and relay software has
  transitioned in stable releases to SHA-256 and Ed25519, which are
  adequate for the foreseeable future. And Tor is expected to
  transition onion services to these cryptographic primitives within
  the year.  Therefore, any valid objections based on this concern
  will be short-lived. More important, when combined, onion
  protections can only add to TLS and certifcate protections. Breaking
  the private RSA-1024 key associated with an onion address that has
  an appropriately stronger TLS key and certificate doesn’t, by
  itself, allow an attacker to subvert a certified TLS session with
  the onionsite. Conversely, MITM, cipher degradation, or other
  certificate or TLS instance attacks aren’t possible with onion
  addresses unless the attacker also breaks the self-authentication.

This was directed at sites that aren't concerned about location
hiding, just better authentication and confidentiality of content.  So
had slightly different context than as Nate is addressing for IoT, but
these points apply whether or not one wants the onion service to be
hidden or not.


> If you add in the extra hidden service authentication feature, it
> also means the Onion service is not even reachable unless you have
> been given the extra special secret cookie/token through another
> channel.
> 
> It is these aspects of Onion services that have drawn me to them for use
> in IoT applications, and I think they are relevant to the exchange of
> sensitive health data, as well.
> 
> Some of what I've been thinking about our outlined in these slides:
> https://github.com/n8fr8/talks/blob/master/onion_things/Internet%20of%20Onion%20Things.pdf

Great slides. Thanks Nate. 

aloha,
Paul