docs/cautions.rst

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