home *** CD-ROM | disk | FTP | other *** search
/ The Hacker's Encyclopedia 1998 / hackers_encyclopedia.iso / pc / crypto / pgpatack.faq < prev    next >
Encoding:
Text File  |  2003-06-11  |  32.3 KB  |  747 lines

  1.     As before, comments, suggestions and corrections are WELCOMED.
  2.  
  3.  
  4.  
  5.  
  6. BETABETABETABETABETABETABETABETABETABETABETABETABETABETABETABETABETABETABETA
  7. BETABETA                                                            BETABETA
  8. BETABETA                                                            BETABETA
  9. BETABETA          This is NOT done.                                 BETABETA
  10. BETABETA    There are entire sections unfinished.  The elipsis      BETABETA
  11. BETABETA    indicates a section is underconstruction...             BETABETA
  12. BETABETA                                                            BETABETA
  13. BETABETABETABETABETABETABETABETABETABETABETABETABETABETABETABETABETABETABETA
  14. BETABETABETABETABETABETABETABETABETABETABETABETABETABETABETABETABETABETABETA
  15.  
  16.  
  17.             [ The Feasibility of Breaking PGP ]
  18.             [ The PGP attack FAQ ]
  19.  
  20.           12/95     v.10 [beta]
  21.  
  22.  
  23.           by infiNity [daemon9@netcom.com / route@infonexus.com]
  24.  
  25.  
  26.        -- [Brief introduction] --
  27.  
  28.     This FAQ is a small side project I have decided to undertake.
  29.     It was originally just going to be a rather lengthy spur-of-the
  30.     moment post to alt.2600 in order to clear up some incorrect
  31.     assumptions and perceptions people had about the security of
  32.     PGP.  It has grown well beyond that...
  33.  
  34.     There are a great many misconceptions out there about how
  35.     vulnerable Pretty Good Privacy is to attack.  This FAQ is designed
  36.     to shed some light on the subject.  It is not an introduction to
  37.     PGP or cryptography.  If you are not at least conversationally
  38.     versed in either topic, readers are directed to The Infinity Concept
  39.     issue 1, and the sci.crypt FAQ.  Both documents are available via
  40.     ftp from infonexus.com.  This document can be found there
  41.     as well (/pub/Philes/Cryptography/PGPattackFAQ.txt.gz).
  42.  
  43.     PGP is a hybrid cryptosystem.  It is made up of 4 crytpographic
  44.     elements: It contains a symmetric cipher (IDEA), an asymmetric cipher
  45.     (RSA), a one-way hash (MD5), and a random number generator (Which is
  46.     two-headed, actually:  it samples entropy from the user and then
  47.     uses that to seed a PRNG).  Each is subject to a different form of
  48.     attack.
  49.  
  50.  
  51.        1 -- [The Symmetric Cipher] -- 1
  52.  
  53.     IDEA, finalized in 1992 by Lai and Massey is a block cipher that
  54.     operates on 64-bit blocks of data.  There have be no advances
  55.     in the cryptanalysis of standard IDEA that are publically known.
  56.     (I know nothing of what the NSA has done, nor does most anyone.)
  57.     The only method of attack, therefore, is brute force.
  58.  
  59.     -- Brute Force of IDEA --
  60.  
  61.     As we all know the keyspace of IDEA is 128-bits.  In base 10
  62.     notation that is:
  63.  
  64.       340,282,366,920,938,463,463,374,607,431,768,211,456.
  65.  
  66.     To recover a particular key, one must, on average, search half the
  67.     keyspace.  That is 127 bits:
  68.  
  69.       170,141,183,460,469,231,731,687,303715,884,105,728.
  70.  
  71.     If you had 1,000,000,000 machines that could try 1,000,000,000
  72.     keys/sec, it would still take all these machines longer than the
  73.     universe as we know it has existed and then some, to find  the key.
  74.     IDEA, as far as present technology is concerned, is not vulnerable to
  75.     attack, pure and simple.
  76.  
  77.     -- Other attacks against IDEA --
  78.  
  79.     If we cannot crack the cipher, and we cannot brute force the
  80.     key-space, what if we can find some weakness in the PRNG used
  81.     by PGP to generate the psuedo-random IDEA session keys?  This
  82.     topic is covered in more detail in section 4.
  83.  
  84.  
  85.  
  86.        2 -- [The Asymmetric Cipher] -- 2
  87.  
  88.     RSA, the first full fledged public key cryptosystem was designed
  89.     by Rivest, Shamir, and Adleman in 1977.  RSA gets it's security from
  90.     the apparent difficulty in factoring very large composites.
  91.     However, nothing has been proven with RSA.  It is not proved
  92.     that factoring the public modulous is the only (best) way to
  93.     break RSA.  There may be an as yet undiscovered way to break it.
  94.     It is also not proven that factoring *has* to be as hard as it is.
  95.     There exists the possiblity that an advance in number theory may lead
  96.     to the discovery of a polynomial time factoring algorithm.  But, none
  97.     of these things has happened, and no current research points in that
  98.     direction.  However, 3 things that are happening and will continue
  99.     to happen that take away from the security of RSA are: the advances
  100.     in factoring technique, computing power and the decrease in the
  101.     cost of computing hardware.  These things, especially the first one,
  102.     work against the security of RSA.  However, as computing power
  103.     increases, so does the ability to generate larger keys.  It is *much*
  104.     easier to multiply very large primes than it is to factor the
  105.     resulting composite (given today's understanding of number theory).
  106.  
  107.     -- The math of RSA in 7 fun-filled steps --
  108.  
  109.     To understand the attacks on RSA, it is  important to understand
  110.     how RSA works.  Briefly:
  111.  
  112.       - Find 2 very large primes, p and q.
  113.       - Find n=pq (the public modulous).
  114.       - Choose e, such that e<n and relatively prime to (p-1)(q-1).
  115.       - Compute d=e^-1 mod[(p1-)(q-1)]  OR  ed=1[mod (p-1)(q-1)].
  116.       - e is the public exponent and d is the private one.
  117.       - The public-key is (n,e), and the private key is (n,d).
  118.       - p and q should never be revealed, preferably destroyed (PGP
  119.         keeps p and q to speed operations by use of the Chinese Remainder
  120.         Theorem, but they are kept encrypted)
  121.  
  122.       Encryption is done by dividing the target message into blocks
  123.       smaller than n and by doing modular exponentiation:
  124.  
  125.        c=m^e mod n
  126.  
  127.       Decryption is simply the inverse operation:
  128.  
  129.        m=c^d mod n
  130.  
  131.  
  132.     -- Brute Force RSA Factoring --
  133.  
  134.     An attacker has access to the public-key.  In other words, the
  135.     attacker has e and n.  The attacker wants the private key.  In
  136.     other words the attacker wants d.  To get d, n needs to be
  137.     factored (which will yield p and q, which can then be used to
  138.     calculate d).  Factoring n is the best known attack against RSA to
  139.     date.  (Attacking RSA by trying to deduce (p-1)(q-1) is no easier
  140.     than factoring n, and executing an exhaustive search for values of d
  141.     is harder than factoring n.)  Some of the algorithms used for
  142.     factoring are as follows:
  143.  
  144.     - Trial division:  The oldest and least efficient.  Exponential
  145.     running time.  Try all the prime numbers <= sqrt(n).
  146.  
  147.     - Quadratic Sieve (QS):  The fastest algorithm for numbers smaller
  148.     than 110 digits.
  149.  
  150.     - Multiple Polynomial Quadratic Sieve (MPQS):  Faster version of QS.
  151.  
  152.     - Double Large Prime Variation of the MPQS:  Faster still.
  153.  
  154.     - Number Field Sieve (NFS):  Currently the fastest algorithm known for
  155.     numbers larger than 110 digits.  Was used to factor the ninth Fermat
  156.     number.
  157.  
  158.     These algorithms represent the state of the art in warfare against
  159.     large composite numbers (therefore agianst RSA).  The best algorithms
  160.     have a super-polynomial (sub-exponential) running time, with the NFS
  161.     having an asypmtotic time estimate closest to polynomial behaivior.
  162.  
  163.     Still, factoring large numbers is hard.  However, with the advances
  164.     in number theory and computing power, it is getting easier.  In 1977
  165.     Ron Rivest said that factoring a 125-digit number would take
  166.     40 quadrillion years.  In 1994 RSA129 was factored using about
  167.     5000 MIPS-years of effort from idle CPU cycles on computers across
  168.     the Internet for eight months.  In 1995 the Blacknet key (116 digits)
  169.     was factored using about 400 MIPS-years of effort (1 MIPS-year is
  170.     a 1,000,000 instruction per second computer running for one year)
  171.     from several dozen workstations and a MasPar for about three months.
  172.     Given current trends the keysize that can be factored will only
  173.     increase as time goes on.  The table below estimates the effort
  174.     required to factor some common PGP-based RSA public-key modulous
  175.     lengths using the General Number Field Sieve:
  176.  
  177.  
  178.       KeySize       MIPS-years required to factor
  179.     -----------------------------------------------------------------
  180.       512           30,000
  181.       768           200,000,000
  182.       1024          300,000,000,000
  183.       2048          300,000,000,000,000,000,000
  184.  
  185.  
  186.     The next chart shows some estimates for the equivalences in brute
  187.     force key searches of symmetric keys and brute force factoring
  188.     of asymmetric keys, using the NFS.
  189.  
  190.  
  191.       Symmetric        Asymmetric
  192.     ------------------------------------------------------------------
  193.       56-bits          384-bits
  194.       64-bits          512-bits
  195.       80-bits          768-bits
  196.       112-bits        1792-bits
  197.       128-bits        1304-bits
  198.  
  199.  
  200.     It was said by the 4 men who factored the Blacknet key that
  201.     "Organizations with 'more modest' resources can almost certainly
  202.     break 512-bit keys in secret right now."  This is not to say
  203.     that such an organization would be interested in devoting so
  204.     much computing power to break just anyone's messages.  However, most
  205.     people using cryptography do not rest comfortably knowing the
  206.     system they trust their secrets to can be broken...
  207.  
  208.     My advice as always is to use the largest key allowable by the
  209.     implementation.  If the implementation does not allow for large
  210.     enough keys to satisfy your paranoia, do not use that implementation.
  211.  
  212.  
  213.     -- Esoteric RSA attacks --
  214.  
  215.     These attacks do not exhibit any profound weakness in RSA itself,
  216.     just in certian implementations of the protocol.  Most are not
  217.     issues in PGP.
  218.  
  219.     -- Choosen cipher-text attack --
  220.  
  221.     An attacker listens in on the insecure channel in which RSA
  222.     messages are passed.  The attacker collects an encrypted message
  223.     c, from the target (destined for some other party).  The attacker
  224.     wants to be able to read this message without having to mount a
  225.     serious factoring effort.  In other words, she wants m=c^d.
  226.  
  227.     To recover m, the attacker first chooses a random number, r<n.
  228.     (The attacker has the public-key (e,n).)  The attacker computes:
  229.  
  230.       x=r^e mod n (She encrypts r with the target's public-key)
  231.  
  232.       y=xc mod n (Multiplies the target ciphertext with the temp)
  233.  
  234.       t=r^-1 mod n (Multiplicative inverse of r mod n)
  235.  
  236.     The attacker counts on the fact property that:
  237.  
  238.       If x=r^e mod n, Then r=x^d mod n
  239.  
  240.     The attacker then gets the target to sign y with her private-key,
  241.     (which actually decyrpts y) and sends u=y^d mod n to the
  242.     attacker.  The attacker simply computes:
  243.  
  244.     tu mod n = (r^-1)(y^d) mod n = (r^-1)(x^d)(c^d) mod n = (c^d) mod n
  245.  
  246.             = m
  247.  
  248.     To foil this attack do not sign some random document presented to
  249.     you.  Sign a one-way hash of the message instead.
  250.  
  251.     -- Low encryption exponent e --
  252.  
  253.     As it turns out, e being a small number does not take away from the
  254.     security of RSA.  If the encryption exponent is small (common values
  255.     are 3,17, and 65537) then public-key operations are significantly
  256.     faster.  The only problem in using small values for e  as a public
  257.     exponent is in encrypting small messages.  If we have 3 as our e
  258.     and we have an m smaller than the cubic root of n, then the message
  259.     can be recovered simply by taking the cubic root of m beacuse:
  260.  
  261.       m [for m<= 3rdroot(n)]^3 mod n will be equivalent to m^3
  262.  
  263.       and therefore:
  264.  
  265.       3rdroot(m^3) = m.
  266.  
  267.     To defend against this attack, simply pad the message with a nonce
  268.     before encryption, such that m^3 will always be reduced mod n.
  269.  
  270.     PGP uses a small e for the encryption exponent, by default it tries
  271.     to use 17.  If it cannot compute d with e being 17, PGP will iterate
  272.     e to 19, and try again...  PGP also makes sure to pad m with a random
  273.     value so m > n.
  274.  
  275.  
  276.     -- Timing attack against RSA --
  277.  
  278.     A very new area of attack publically discovered by Paul Kocher deals
  279.     with the fact that different crytpographic operations (in this case
  280.     the modular exponentiation operations in RSA) take discretely different
  281.     amounts of time to process.  If the RSA computations are done without
  282.     the Chinese Remainder theorem, the following applies:
  283.  
  284.     An attacker can exploit slight timing differences in RSA computations
  285.     to, in many cases, recover d.  The attack is a passive one that where
  286.     the attacker sits on a network and is able to observe the RSA
  287.     operations.
  288.  
  289.     The attacker passively observes k operations measuring the time t
  290.     it takes to compute each modular exponentation operation:
  291.     m=c^d mod n.  The attacker also knows c and n.  The psuedo code of
  292.     the attack:
  293.  
  294.     Algorithm to compute m=c^d mod n:
  295.  
  296.     Let m0 = 1.
  297.     Let c0 = x.
  298.     For i=0 upto (bits in d-1):
  299.       If (bit i of d) is 1 then
  300.        Let mi+1 = (mi * ci) mod n.
  301.       Else
  302.        Let mi+1 = mi.
  303.       Let di+1 = di^2 mod n.
  304.     End.
  305.  
  306.     This is very new (the public announcement was made on 12/7/95)
  307.     and intense scrutiny of the attack has not been possible.  However,
  308.     Ron Rivest had this to say about countering it:
  309.  
  310. -------------------------------------------BEGIN INCLUDED TEXT---------------
  311.  
  312. From: Ron Rivest <rivest>
  313. Newsgroups: sci.crypt
  314. Subject: Re: Announce: Timing cryptanalysis of RSA, DH, DSS
  315. Date: 11 Dec 1995 20:17:01 GMT
  316. Organization: MIT Laboratory for Computer Science
  317.  
  318. The simplest way to defeat Kocher's timing attack is to ensure that the
  319. cryptographic computations take an amount of time that does not depend on the
  320. data being operated on.  For example, for RSA it suffices to ensure that
  321. a modular multiplication always takes the same amount of time, independent of
  322. the operands.
  323.  
  324. A second way to defeat Kocher's attack is to use blinding: you "blind" the
  325. data beforehand, perform the cryptographic computation, and then unblind
  326. afterwards.  For RSA, this is quite simple to do.  (The blinding and
  327. unblinding operations still need to take a fixed amount of time.) This doesn't
  328. give a fixed overall computation time, but the computation time is then a
  329. random variable that is independent of the operands.
  330. -
  331. ==============================================================================
  332. Ronald L. Rivest  617-253-5880  617-253-8682(Fax) rivest@theory.lcs.mit.edu
  333. ==============================================================================
  334.  
  335. ---------------------------------------------END INCLUDED TEXT---------------
  336.  
  337.  
  338.     PGP is not vulnerable to the timing attack as it uses the CRT to
  339.     speed RSA operations.  Also, since the timing attack requires an
  340.     attacker to observe the cryptographic operations in real time (ie:
  341.     snoop the decryption process from start to finish) and most people
  342.     encrypt and decrypt off-line, it is further made inpractical.
  343.  
  344.  
  345.     -- Other RSA attacks --
  346.  
  347.     There are other attacks against RSA, such as the common modulous
  348.     attack in which several users share n, but have different values
  349.     for e and d.  Sharing a common modulous with several users, can
  350.     enable an attacker to recover a message without factoring n.  PGP
  351.     does not share public-key modulous' among users.
  352.  
  353.     If d is up to one quarter the size of n and e is less than n, d
  354.     can be recovered without factoring.  PGP does not choose small
  355.     values for the decryption exponent.  (If d were too small it might
  356.     make a brute force sweep of d values feasible which is obviously a
  357.     bad thing.)
  358.  
  359.  
  360.     -- Keysizes --
  361.  
  362.     It is pointless to make predictions for recommended keysizes.
  363.     The breakneck speed at which technology is advancing makes it
  364.     difficult and dangerous.  Respected cryptographers will not make
  365.     predictions past 10 years and I won't embarass myself trying to
  366.     make any.  For today's secrets, a 1024-bit is probably safe and
  367.     a 2048-bit key definitely is.  I wouldn't trust these numbers
  368.     past the end of the century.  However, it is worth mentioning that
  369.     RSA would not have lastest this long if it was as fallible as some
  370.     crackpots with middle initials would like you to believe.
  371.  
  372.  
  373.  
  374.        3 -- [The one-way hash] -- 3
  375.  
  376.  
  377.     MD5 is the one-way hash used to hash the passphrase into the IDEA
  378.     key and to sign documents.  Message Digest 5 was designed by Rivest
  379.     as a sucessor to MD4 (which was found to be weakened with reduced
  380.     rounds).  It is slower but more secure.  Like all one-way hash
  381.     functions, MD5 takes an arbitrary-length input and generates a unique
  382.     output.
  383.  
  384.     -- Brute Force of MD5 --
  385.  
  386.     The strength of any one-way hash is defined by how well it can
  387.     randomize an arbirary message and produce a unique output.  There
  388.     are two types of brute force attacks against a one-way hash
  389.     function, pure brute force (my own terminolgy) and the birthday
  390.     attack.
  391.  
  392.  
  393.     -- Pure Brute Force Attack against MD5 --
  394.  
  395.  
  396.     The output of MD5 is 128-bits.  In a pure brute force attack,
  397.     the attacker has access to the hash of message H(m).  She wants
  398.     to find another message m' such that:
  399.  
  400.        H(m) = H(m').
  401.  
  402.     To find such message (assuming it exists) it would take a machine
  403.     that could try 1,000,000,000 messages per second about 1.07E22
  404.     years.  (To find m would require the same amount of time.)
  405.  
  406.  
  407.     -- The birthday attack against MD5 --
  408.  
  409.     Find two messages that hash to the same value is known as a collision
  410.     and is exploited by the birthday attack.
  411.  
  412.     The birthday attack is a statistical probability problem.  Given
  413.     n inputs and k possible outputs, (MD5 being the function to take
  414.     n -> k) there are n(n-1)/2 pairs of inputs.  For each pair, there
  415.     is a probability of 1/k of both inputs producing the same output.
  416.     So, if you take k/2 pairs, the probability will be 50% that a
  417.     matching pair will be found.  If n > sqrt(k), there is a good chance
  418.     of finding a collision.  In MD5's case, 2^64 messages need to be
  419.     tryed.  This is not a feasible attack given today's technology.  If
  420.     you could try 1,000,000 messages per second, it would take 584,942
  421.     years to find a collision. (A machine that could try 1,000,000,000
  422.     messages per second would take 585 years, on average.)
  423.  
  424.     For a successful account of the birthday against crypt(3), see:
  425.     url:
  426.  
  427.    ftp://ftp.infonexus.com/pub/Philes/Cryptography/crypt3Collision.txt.gz
  428.  
  429.  
  430.     -- Other attacks against MD5 --
  431.  
  432.     Differential cryptanalysis has proven to be effective against one
  433.     round of MD5, but not against all 4 (differential cryptanalysis
  434.     looks at ciphertext pairs whose plaintexts has specfic differences
  435.     and analyzes these differences as they propagate through the cipher).
  436.  
  437.     There was successful attack at compression function itself that
  438.     produces collsions, but this attack has no practical impact the
  439.     security.  If your copy of PGP has had the MD5 code altered to
  440.     cause these collisions, it would fail the message digest
  441.     verification and you would reject it as altered... Right?
  442.  
  443.  
  444.     -- Passphrase Length and Information Theory --
  445.  
  446.     According to conventional information theory, the English language
  447.     has about 1.3 bits of entropy (information) per 8-bit character.
  448.     If the pass phrase entered is long enough, the reuslting MD5 hash will
  449.     be statiscally random.  For the 128-bit output of MD5, a pass phrase
  450.     of about 98 characters will provide a random key:
  451.  
  452.       (8/1.3) * (128/8) = (128/1.3) = 98.46 characters
  453.  
  454.     How many people use a 98 character passphrase for you secret-key
  455.     in PGP?  Below is 98 characters...
  456.  
  457.     123456789012345678901234567890123456789012356789012345678901234567\
  458.     \890123456789012345678
  459.  
  460.     1.3 comes from the fact that an arbitrary readable English sentence
  461.     is usally going to consist of certian letters, thereby reducing it's
  462.     entropy.  If any of the 26 letters in the Latin alphabet were equally
  463.     possible and likely (which is seldom the case) the entropy increases.
  464.     The so-called absolute rate would in this case, is:
  465.  
  466.       log(26) / log(2) = 4.7 bits
  467.  
  468.     In this case of increased entropy, a password with a truly random
  469.     sequence of English characters will only need to be:
  470.  
  471.       (8/4.7) * (128/8) = (128/4.7) = 27.23 characters
  472.  
  473.  
  474.        4 -- [The PRNG] -- 4
  475.  
  476.  
  477.     PGP employs 2 PRNG's to generate and manipulate (psuedo) random data.
  478.     The ANSI X9.17 generator and a function which measures the entropy
  479.     from the latency in a user's keystrokes.  The random pool (which is
  480.     the randseed.bin file) is used to seed the ANSI X9.17 PRNG (which uses
  481.     IDEA, not 3DES).  Randseed.bin is initially generated from trueRand
  482.     which is the keystroke timer.  The X9.17 generator is pre-washed with an
  483.     MD5 hash of the plaintext and postwashed with some random data which is
  484.     used to generate the next randseed.bin file.  The process is broken up
  485.     and discussd below.
  486.  
  487.  
  488.     -- ANSI X9.17 (cryptRand) --
  489.  
  490.     The ANSI X9.17 is the method of key generation PGP uses. It is
  491.     oficially specified using 3DES, but was easily converted to IDEA.  It
  492.     works as follows:
  493.  
  494.     E() = an IDEA encryption, with a reusable key used for key generation
  495.     T = timestamp (data from randseed.bin used in place of timestamp)
  496.     V = Initialization Vector, from randseed.bin
  497.     R = random session key to be generated
  498.  
  499.     R = E[E(T) XOR V]
  500.  
  501.     the next V is generated thusly:
  502.  
  503.     V = E[E(T) XOR R]
  504.  
  505.     -- Latency Timer (trueRand) --
  506.  
  507.     The trueRand generator attempts to measure entropy from the latency
  508.     of a user's keystrokes every time the user types on the keyboard.  It
  509.     is used to generate the initial randseed.bin which is in turn used to
  510.     seed to X9.17 generator.
  511.     The quality of the output of trueRand is dependent upon it's input.
  512.     If the input has a low amount of entropy, the output will not be as
  513.     random as possible....
  514.  
  515.  
  516.     -- X9.17 Prewash with MD5 --
  517.  
  518.     In most situations, the attacker does not know the content of the
  519.     plaintext being encrypted by PGP.  So, in most cases, washing the
  520.     X9.17 generator with an MD5 hash of the plaintext, simply adds to
  521.     security.  This is based on the assumption that this added unknown
  522.     information will add to the entropy of the generator.
  523.     If, in the event that the attacker has some information about the
  524.     plaintext (perhaps the attacker knows which file was encrypted, and
  525.     wishes to prove this fact) the attacker may be able to execute a
  526.     known-plaintext attack against X9.17.  However, it is not likely
  527.     that, with all the other precautions taken, that this would weaken
  528.     the generator.
  529.  
  530.  
  531.  
  532.  
  533.  
  534.  
  535.  
  536.        5 -- [Practical Attacks] -- 5
  537.  
  538.     Most of the attacks outlined above are either not possible or not
  539.     fesaible by the average adversary.  So, what can the average cracker
  540.     do to subvert the otherwise stalwart security of PGP?  As it turns,
  541.     there are several "doable" attacks that can be launched by the typcial
  542.     cracker.  They do not attack the cryptosystem protocols themselves,
  543.     (which have shown to be secure) but rather system specific
  544.     implementations of PGP.
  545.  
  546.  
  547.     -- Passive Attacks (Snooping) --
  548.  
  549.     These attacks do not do need to do anything proactive and can easily
  550.     go undetected.
  551.  
  552.     -- Keypress Snooping  --
  553.  
  554.     Still a very effective method of attack, keypress snooping can subvert
  555.     the security of the strongest cryptosystem.  If an attacker can
  556.     install a keylogger, and capture the passphrase of an unwary target,
  557.     then no cryptanalysis whatsoever is necessary.  The attacker has the
  558.     passphrase to unlock the RSA private key.  The system is completely
  559.     compromised.
  560.     The methods vary from system to system, but I would say DOS-based PGP
  561.     would be the most vulnerable.  DOS is the easiest OS to subvert, and
  562.     has the most key-press snooping tools that I am aware of.  All an
  563.     attacker would have to do would be gain access to the machine for
  564.     under 5 minutes on two seperate occasions and the attack would be
  565.     complete.  The first time to install the snooping software, the second
  566.     time, to remove it, and recover the goods. (If the machine is on a
  567.     network, this can all be done *remotely* and the ease of the attack
  568.     increases greatly.)  Even if the target boots clean, not loading any
  569.     TSR's, a boot sector virus could still do the job, transparently.
  570.     Keypress snooping under Unix is a bit more complicated, as root
  571.     access is needed, unless the target is entering her passphrase from
  572.     an X-Windows GUI.  There are numerous key loggers available to
  573.     passively observe keypresses from an X-Windows session.
  574.  
  575.     -- Van Eck Snooping --
  576.  
  577.     The original invisible threat.  Below is a clip from a posting by
  578.     noted information warfare guru Winn Schwartau describing a Van Eck
  579.     attack:
  580.  
  581. -------------------------------------------BEGIN INCLUDED TEXT---------------
  582.  
  583. Van Eck Radiation Helps Catch Spies
  584.  
  585. "Winn Schwartau" < p00506@psilink.com >
  586. Thu, 24 Feb 94 14:13:19 -0500
  587.  
  588.  
  589. Van Eck in Action
  590.  
  591. Over the last several years, I have discussed in great detail how the
  592. electromagnetic emissions from personal computers (and electronic gear in
  593. general) can be remotely detected without a hard connection and the
  594. information on the computers reconstructed.  Electromagnetic eavesdropping is
  595. about insidious as you can get: the victim doesn't and can't know that anyone
  596. is 'listening' to his computer.  To the eavesdropper, this provides an ideal
  597. means of surveillance: he can place his eavesdropping equipment a fair
  598. distance away to avoid detection and get a clear representation of what is
  599. being processed on the computer in question.  (Please see previous issues of
  600. Security Insider Report for complete technical descriptions of the
  601. techniques.)
  602.  
  603. The problem, though, is that too many so called security experts, (some
  604. prominent ones who really should know better) pooh-pooh the whole concept,
  605. maintaining they've never seen it work.  Well, I'm sorry that none of them
  606. came to my demonstrations over the years, but Van Eck radiation IS real and
  607. does work.  In fact, the recent headline grabbing spy case illuminates the
  608. point.
  609.  
  610. Exploitation of Van Eck radiation appears to be responsible, at least in part,
  611. for the arrest of senior CIA intelligence officer Aldrich Hazen Ames on
  612. charges of being a Soviet/Russian mole.  According to the Affidavit in support
  613. of Arrest Warrant, the FBI used "electronic surveillance of Ames' personal
  614. computer and software within his residence," in their search for evidence
  615. against him.  On October 9, 1993, the FBI "placed an electronic monitor in his
  616. (Ames') computer," suggesting that a Van Eck receiver and transmitter was used
  617. to gather information on a real-time basis.  Obviously, then, this is an ideal
  618. tool for criminal investigation - one that apparently works quite well.  (From
  619. the Affidavit and from David Johnston, "Tailed Cars and Tapped Telephones: How
  620. US Drew Net on Spy Suspects," New York Times, February 24, 1994.)
  621.  
  622. >From what we can gather at this point, the FBI black-bagged Ames' house and
  623.  
  624. installed a number of surveillance devices.  We have a high confidence factor
  625. that one of them was a small Van Eck detector which captured either CRT
  626. signals or keyboard strokes or both.  The device would work like this:
  627.  
  628. A small receiver operating in the 22MHz range (pixel frequency) would detect
  629. the video signals minus the horizontal and vertical sync signals.  Since the
  630. device would be inside the computer itself, the signal strength would be more
  631. than adequate to provide a quality source.  The little device would then
  632. retransmit the collected data in real-time to a remote surveillance vehicle or
  633. site where the video/keyboard data was stored on a video or digital storage
  634. medium.
  635.  
  636. At a forensic laboratory, technicians would recreate the original screens and
  637. data that Mr. Ames entered into his computer.  The technicians would add a
  638. vertical sync signal of about 59.94 Hz, and a horizontal sync signal of about
  639. 27KHz.  This would stabilize the roll of the picture. In addition, the
  640. captured data would be subject to "cleansing" - meaning that the spurious
  641. noise in the signal would be stripped using Fast Fourier Transform techniques
  642. in either hardware or software.  It is likely, though, that the FBI's device
  643. contained within it an FFT chip designed by the NSA a couple of years ago to
  644. make the laboratory process even easier.
  645.  
  646. I spoke to the FBI and US Attorney's Office about the technology used for
  647. this, and none of them would confirm or deny the technology used "on an active
  648. case."
  649.  
  650. Of course it is possible that the FBI did not place a monitoring device within
  651. the computer itself, but merely focused an external antenna at Mr. Ames'
  652. residence to "listen" to his computer from afar, but this presents additional
  653. complexities for law enforcement.
  654.  
  655.      1. The farther from the source the detection equipment sits means that
  656. the detected information is "noisier" and requires additional forensic
  657. analysis to derive usable information.
  658.  
  659.      2. Depending upon the electromagnetic sewage content of the immediate
  660. area around Mr. Ames' neighborhood, the FBI surveillance team would be limited
  661. as to what distances this technique would still be viable.  Distance squared
  662. attenuation holds true.
  663.  
  664.      3. The closer the surveillance team sits to the target, the more likely
  665. it is that their activities will be discovered.
  666.  
  667. In either case, the technology is real and was apparently used in this
  668. investigation.  But now, a few questions arise.
  669.  
  670.      1.  Does a court surveillance order include the right to remotely
  671. eavesdrop upon the unintentional emanations from a suspect's electronic
  672. equipment?  Did the warrants specify this technique or were they shrouded
  673. under a more general surveillance authorization?  Interesting question for the
  674. defense.
  675.  
  676.      2. Is the information garnered in this manner admissible in court?  I
  677. have read papers that claim defending against this method is illegal in the
  678. United States, but I have been unable to substantiate that supposition.
  679.  
  680.      3. If this case goes to court, it would seem that the investigators would
  681. have to admit HOW they intercepted signals, and a smart lawyer (contradictory
  682. allegory :-) would attempt to pry out the relevant details.  This is important
  683. because the techniques are generally classified within the intelligence
  684. community even though they are well understood and explained in open source
  685. materials.  How will the veil of national security be dropped here?
  686.  
  687. To the best of my knowledge, this is the first time that the Government had
  688. admitted the use of Van Eck (Tempest Busting etc.)  in public.  If anyone
  689. knows of any others, I would love to know about it.
  690.  
  691. ---------------------------------------------END INCLUDED TEXT---------------
  692.  
  693.     The relevance to PGP is obvious, and the threat is real.  Snooping
  694.     the passphrase from the keyboard, and even whole messages from
  695.     the screen are viable attacks.  This attack, however exotic it may
  696.     seem, is not beyond the capability of anyone with some technical
  697.     know-how and the desire to read PGP encrypted files.
  698.  
  699.     -- Memory Space Snooping --
  700.  
  701.     In a multi-user system such as Unix, the physical memory of the
  702.     machine can be examined by anyone with the proper privaleges (usally
  703.     root).  In comparsion with factoring a huge composite number, opening
  704.     up the virtual memory of the system (/dev/kmem) and directly reading
  705.     a user's page is trivial.
  706.  
  707.  
  708.     -- Disk Cache Snooping --
  709.  
  710.     In multitasking environments such as Windows, the OS has a nasty habit
  711.     of paging the contents of memory to disk.  This is the last thing a
  712.     PGP user wants...
  713.  
  714.  
  715.     -- Packet Sniffing --
  716.  
  717.  
  718.     -- Active Attacks --
  719.  
  720.     These attacks
  721.  
  722.     -- Trojan Horse --
  723.  
  724.     -- Reworked Code --
  725.  
  726.     Verify the checksum
  727.  
  728.  
  729.        -- [Closing Comments] --
  730.  
  731.  
  732.        -- [Thank You's] --
  733.  
  734.     PRZ, Paul Kocher, Bruce Schneier, Paul Rubin, Stephen McCluskey, Adam
  735.     Back
  736.  
  737.  
  738. --
  739.  ----| Infinity / Route / daemon9 |--------|--------{ route@infonexus.com }--
  740. --| Founding member: The 0x47 0x75 0x69 0x6C 0x64 | Finger for information |--
  741.     [RSADSALUCGARGOYLEIDEADESLUCIFERLOKIFEALSHAMD5HAVALSNEFRU]
  742.       Business wants to make money, Government wants to have control.
  743.        Our privacy is at stake.  Use strong cryptography.
  744. --- ifmail v.2.8.lwz
  745.  * Origin: NETCOM On-line Communication Services (408 261-47 (1:340/13@fidonet)
  746.  
  747.