docs/cautions.rst

   1 .. -*- coding: utf-8-with-signature -*-
   2
   3 =======================================================
   4  Things To Be Careful About As We Venture Boldly Forth
   5 =======================================================
   6
   7 See also known_issues.rst_.
   8
   9 .. _known_issues.rst: known_issues.rst
  10
  11 Timing Attacks
  12 ==============
  13
  14 Asymmetric-key cryptography operations are particularly sensitive to
  15 side-channel attacks. Unless the library is carefully hardened against timing
  16 attacks, it is dangerous to allow an attacker to measure how long signature
  17 and pubkey-derivation operations take. With enough samples, the attacker can
  18 deduce the private signing key from these measurements. (Note that
  19 verification operations are only sensitive if the verifying key is secret,
  20 which is not the case for anything in Tahoe).
  21
  22 We currently use private-key operations in mutable-file writes, and
  23 anticipate using them in signed-introducer announcements and accounting
  24 setup.
  25
  26 Mutable-file writes can reveal timing information to the attacker because the
  27 signature operation takes place in the middle of a read-modify-write cycle.
  28 Modifying a directory requires downloading the old contents of the mutable
  29 file, modifying the contents, signing the new contents, then uploading the
  30 new contents. By observing the elapsed time between the receipt of the last
  31 packet for the download, and the emission of the first packet of the upload,
  32 the attacker will learn information about how long the signature took. The
  33 attacker might ensure that they run one of the servers, and delay responding
  34 to the download request so that their packet is the last one needed by the
  35 client. They might also manage to be the first server to which a new upload
  36 packet is sent. This attack gives the adversary timing information about one
  37 signature operation per mutable-file write. Note that the UCWE
  38 automatic-retry response (used by default in directory modification code) can
  39 cause multiple mutable-file read-modify-write cycles per user-triggered
  40 operation, giving the adversary a slightly higher multiplier.
  41
  42 The signed-introducer announcement involves a signature made as the client
  43 node is booting, before the first connection is established to the
  44 Introducer. This might reveal timing information if any information is
  45 revealed about the client's exact boot time: the signature operation starts a
  46 fixed number of cycles after node startup, and the first packet to the
  47 Introducer is sent a fixed number of cycles after the signature is made. An
  48 adversary who can compare the node boot time against the transmission time of
  49 the first packet will learn information about the signature operation, one
  50 measurement per reboot. We currently do not provide boot-time information in
  51 Introducer messages or other client-to-server data.
  52
  53 In general, we are not worried about these leakages, because timing-channel
  54 attacks typically require thousands or millions of measurements to detect the
  55 (presumably) small timing variations exposed by our asymmetric crypto
  56 operations, which would require thousands of mutable-file writes or thousands
  57 of reboots to be of use to the adversary. However, future authors should take
  58 care to not make changes that could provide additional information to
  59 attackers.