[Cryptography] Lavabit's and Snowden's Solos

[Ladar Levison]

On 3/21/2016 6:43 PM, Tom Mitchell wrote:
> Q: What if the request was to disable all such shields and allow an
> armada of systems to
> challenge one or more accounts or services with relentless coordinated
> login attacks?
>
> What would be the impact be on the community services?
> Would colateral damage to such a system be allowed by law?
> Would the demand switch from access to surveillance (requires
> speculation)?
>
> Routing tables.. can all traffic into and out of a company like
> lavabit be forced
> through routing resources with packet snooping abilities
> owned/controlled by 
> the FBI even if the bandwidth was maintained.  

Not sure where you're going with these questions but...

Compelled code modification is still a murky area of law. My opinion is
the answer remains no, they can't compel you to make changes, including
disable security "shields." Of course the Apple case will test that, if
it goes forward. That said, they have compelled config changes in the
past. Hushmail enabled a "debug" config setting and used it to steal a
private key during login (at the request of the FBI). Phone companies
have been forced to modify switch settings to allow wiretapping, or
tracing. All of the cases I know of involve config settings, not code
modifications (at least for surveillance purposes). Its worth noting
that there is a body of case law on this topic resulting from FISC
warrants. Of course its classified, which is disturbing, but also means
it can't be cited as a precedent (outside of the FISC).

The impact would depend on the service, and the amount of infrastructure
they have to support the additional load. That said, botnets attack
service providers all the time. If the system is designed correctly, it
should slow things down, but wouldn't knock them offline. Also, if all
your talking about is brute forcing a login, that requires relatively
little processing, even less if the app node already has the information
cached. Your biggest concerns are likely simultaneous connections (async
IO would help with this), and bandwidth.

Typically law enforcement doesn't like to tip off a suspect they're
going after them. So collateral damage that might  provide a tip off
would be avoided. If you mean collateral damage to the service provider,
we'll it's pretty clear they don't care. From where the FBI/DoJ sits,
the stronger the security, the bigger the sledgehammer they'll use.
They've even gone so far as to say its the provider's fault for making
the system secure, so the provider should pay the price of helping them
break in. In other words its Apple (and Lavabit's) fault they can't do
what were asking. It all comes back to the fact that law enforcement
feels "entitled" to the plain text data, and like a trust fund baby,
that sense of entitlement means they don't like it when they can't have
something.

In terms of access, federal law prevents LEOs from masquerading as
suspects, even when they know the person's password. Offline attacks are
a different story. So to make this a valid hypothetical, it would have
to be an intelligence agency, botnet, or foreign organization, assuming
its an American service provider. As always, the goal depends on the actor.

All traffic in/out of a company like Lavabit is relatively easy. The
bigger the infrastructure, the harder it becomes. Multiple uplinks makes
things harder, multiple physical locations makes it even tougher,
especially when you start crossing country borders. As for bandwidth, if
law enforcement can compel the upstream provider to provide access, odds
are they can also compel them to provide bandwidth. That's what the FBI
did to Lavabit. Your also assuming they want to send all the packets
somewhere else. It's far more likely the device will employ filtering
rules, and only send out a subset of the data. Even backbone mirrors do
basic filtering at the source.

L~




-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20160324/d3830f8c/attachment.sig>