[tahoe-dev] [cryptography] storage systems as one-way protocols

[Zooko O'Whielacronx]

[adding Cc: tahoe-dev at tahoe-lafs.org to a thread originated on
cryptography at randombit.net:
http://lists.randombit.net/pipermail/cryptography/2010-October/000189.html
]

On Tue, Oct 5, 2010 at 1:04 PM,
<travis+ml-rbcryptography at subspacefield.org> wrote:
> I don't know if anyone else noticed this but...

I think it is mentioned briefly in "Cryptography Engineering" by
Ferguson, Schneier, Kohno.

> However, the converse is not true; the sender can apply a MAC
> to the data to assure the recipient it has not been altered.
>
> Q: Do any storage cryptosystems do this?

Tahoe-LAFS uses a secure hash of the data to ensure integrity of
immutable files and a digital signature on the data to ensure
integrity of mutable files. Neither kind uses a MAC.

>   How do they manage the metadata?

For "metadata" I think of the secure hashes of the immutable files and
the public keys of the mutable files. These are stored in the file
handle for that file. If you store a file handle in a Tahoe-LAFS
directory then it is covered (recursively) by the same crypto design.
How you securely store or transmit a file outside of the Tahoe-LAFS
filesystem is up to you, of course. Be careful out there.

> And since it is unidirectional, any error correction must be of the
> FEC variety; you may not go back in time and send more data.

Hey, Tahoe-LAFS has that! :-)

> Q: What is the analog of a replay attack in the storage crypto
>   context?  Does it have something to do with not maintaining
>   positive control of your storage media at all times?

Mutable files in Tahoe-LAFS have a sequence number which is
incremented whenever a new version of the file is written by an
authorized writer. (An authorized writer is any writer who knows the
private key used to make digital signatures on the file.)

The analogue of replay attack is "rollback attack" in which the
attacker has stored copies of older versions of the file with earlier
sequence numbers and replaces the new version with those older
versions. Tahoe-LAFS as it currently exists has a fairly weak defense
against this attack -- it follows a quorum of currently connected
storage servers, which is good, but it has very weak controls over
which storage servers are currently connected, so a determined
attacker could achieve rollback attack by providing a sufficient
super-majority of all server that you are currently able to connect
to.

We have some ideas about how to further strengthen Tahoe-LAFS against
rollback attack. The limiting factor is developer time. Come help us
out! :-) Here are the related tickets:

http://tahoe-lafs.org/trac/tahoe-lafs/ticket/947# Add file-with-metadata caps
http://tahoe-lafs.org/trac/tahoe-lafs/ticket/955# use client-side
storage to defend against rollback attack
http://tahoe-lafs.org/trac/tahoe-lafs/ticket/956# embed security
metadata in parent directory
http://tahoe-lafs.org/trac/tahoe-lafs/ticket/957# embed security metadata in URL
http://tahoe-lafs.org/trac/tahoe-lafs/ticket/958# LAFS 301 Moved Permanently

Also any improvement which allows the client to better control which
storage servers it will use also strengthens the existing defenses
against rollback attack.


> It may be further simplified, in that the recipient and sender are
> generally the same person.

In Tahoe-LAFS we don't make this assumption.

Regards,

Zooko