Re: How ATM fraud nearly brought down British banking
Is there any comparable fraud with the USA ATM system in recent decades? I've only heard of this type of wholesale fraud in Europe or in pre-1980 USA. - Alex At 01:58 AM 10/22/2005 -0400, R.A. Hettinga wrote: --- begin forwarded text Date: Sat, 22 Oct 2005 01:58:34 -0400 To: Philodox Clips List [EMAIL PROTECTED] From: R.A. Hettinga [EMAIL PROTECTED] Subject: How ATM fraud nearly brought down British banking http://www.theregister.co.uk/2005/10/21/phantoms_and_rogues/print.html -- - Alex Alten - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: [EMAIL PROTECTED]: Skype security evaluation]
On Sun, 23 Oct 2005, Joseph Ashwood wrote: - Original Message - Subject: [Tom Berson Skype Security Evaluation] Tom Berson's conclusion is incorrect. One needs only to take a look at the publicly available information. I couldn't find an immediate reference directly from the Skype website, but it uses 1024-bit RSA keys, the coverage of breaking of 1024-bit RSA has been substantial. The end, the security is flawed. Of course I told them this now years ago, when I told them that 1024-bit RSA should be retired in favor of larger keys, and several other people as well told them. More worrying is the disconnect between the front page summary and the body of the review. If one only reads the summary, then one would only see the gushing praise and not the SSH protocol 1-esque use of a weak CRC as a integrity mechanism (section 3.4.4) or what sounds suspiciously like a exploitable signed vs. unsigned issue in protocol parsing (section 3.4.6). Also disappointing is the focus on the correct implementation of cryptographic primitives (why not just use tested commercial or open-source implementations?) to the exclusion of other more interesting questions (at least to me): - What properties does the proprietary key agreement protocol offer (it sounds a bit like an attenuated version of the SSH-1 KEX protocol and, in particular, doesn't appear to offer PFS). - Does the use of RC4 follow Mantin's recommendations to discard the early, correlated keystream? - How does the use of RC4 to generate RSA keys work when only 64 bits of entropy are collected from Skype's RNG? (Section 3.1) - Why does Skype roll its own entropy collection functions instead of using the platform's standard one? - Ditto the use of standard protocols? (DTLS would seem an especially obvious choice). - What techniques (such as privilege dropping or separation) does Skype use to limit the scope of a network compromise of a Skype client? -d - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: [EMAIL PROTECTED]: Skype security evaluation]
That's a fairly interesting review, and Skype should be commended for
hiring someone to do it. I hope to see more evaluations from vendors
in the future.
However, I have a couple of suggestions.
My understanding of the peer-to-peer key agreement protocol (hereafter
p2pka) is based on section 3.3 and 3.4.2 and is something like this:
A - B: N_ab
B - A: N_ba
B - A: Sign{f(N_ab)}_a
A - B: Sign{f(N_ba)}_b
A - B: Sign{A, K_a}_SKYPE
B - A: Sign{B, K_b}_SKYPE
A - B: Sign{R_a}_a
B - A: Sign{R_b}_b
Session key SK_AB = g(R_a, R_b)
0) The p2pka allows us to use a peer as a signing oracle for nonces by
performing steps 1 through 4. Only the one-wayness of f (specified
only as modified in a standard way) stands in the way of arbitrary
forgery, which would allow us to bypass the security on steps 3, 4, 7,
and 8. It would not stop us from knowing the session key, since there
is no restriction on the form of R_a or R_b.
1) It's not clear that the identity certificates are bound to a
[externally visible] network [source] address at registration time.
IMHO, this would be a good idea.
2) He implicitly ignores the fact that the skype key is a trusted CA,
so skype can impersonate anyone (or delegate that impersonation by
signing a bogus ID). This is obvious to a cryptographer but should be
mentioned for the layperson. An evaluation should explicitly specify
who must be trusted by whom, and everyone must trust the Skype
registrar.
3) It looks like the peer-to-peer communication involves the same key,
SK_AB, in both directions, opening the door for keystream re-use, but
there's 64 bits of presumably random salt so it shouldn't be very
common.
Vagueness:
1) They use an unencrypted 2-byte CRC on each packet between peers.
Undetected modification to a packet is possible, since the CRC is
computed over the encrypted data and stored en clair. In this case,
arbitrary bits can be flipped, the CRC recomputed, and no future
packets depend on the current packet, so there's no tell-tale garbling
afterwards like there is in most other block modes. He alludes to
this in section 3.4.4 but doesn't really specify the impact, merely
compares it to WEP.
2) The session established with the Skype server during registration
is protected with a 256-bit key, which is random, but he doesn't say
how the client and Skype agree on it.
3) It's not clear why they used rc4 instead of ICM to generate key
material, but at least it's not being used for confidentiality.
4) The details of the random number generation are vague (makes a
number of win32 calls).
5) The details of the SK_AB key composition are vague (combined in a
cryptographically-sound way), shown by g in the p2pka above.
6) It doesn't say who sends the nonces first --- is it the recipient
of the connection, or the initiator? Can we DoS people by repeated
connections triggering digital signatures?
7) It doesn't say whether it's a TCP or UDP protocol, what ports it
uses, etc. I'm curious if it will work through NAT at both ends.
8) The skype server's timeout on login passwords can be used for a
denial-of-service against the registration protocol and doesn't affect
username guessing (fixed password variable username, a/k/a reverse
hack).
9) It doesn't specify how the salts used in ICM mode are communicated.
10) It doesn't specify how streams are created and numbered.
It'd be nice to see the protocol clearly specified and analyzed via
automated means (finite state analysis via murphy, etc.).
Obsession with performance:
He makes no fewer than six comments about performance (of the AES
code, of the modular exponentiation, of the primality testing, of
modular inversion, of multi-precision arithmetic libraries, and SHA-1
implementation), which should normally be the least of anyone's
worries, especially cryptographers. Is this is a security evaluation,
or a performance test?
However, since we're talking about real-time audio streams, perhaps
some discussion of the bandwidth and especially latency of the p2p
protocol would be in order. Unfortunately, there's no quantification
(... performs favorably in terms of clock cycle per encryption).
Trust us:
Finally, the whole thing is closed source, so none of it is easily
verifiable. We just have to take his word on it, and often he just
offers opinions (see the complaints of vagueness above).
Summary:
All that having been said, I still have more confidence in Skype than
I did before reading the paper.
--
http://www.lightconsulting.com/~travis/ --
We already have enough fast, insecure systems. -- Schneier Ferguson
GPG fingerprint: 50A1 15C5 A9DE 23B9 ED98 C93E 38E9 204A 94C2 641B
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: EDP (entropy distribution protocol), userland PRNG design
I can't say I a fan of the idea of having multiple ways of mixing entropy into the system. In particular, the idea of producing output by XORing your PRNGs output with the output of a semi-public RNG seems like a bad idea to me, because an attacker can easily control those values by taking over the web server or modifying packets in the network, and if they can somehow predict your PRNG outputs then they will be able to actually control the final output. Is it that XOR is too simple? That is, if I used a secure mixing function (RFC 1750), perhaps a OWF, would this solve the problem? Then an attacker couldn't find a preimage that would produce a chosen output. source(s) -- mixer -- pool -- extractor -- X9.31 I would think you'd want to use an extractor* on the sources before they get commingled with other stuff. Of course the extractor operates on two sources (one weakly random, the other uniformly random) to generate nearly-uniform values, so it is doing a kind of mixing of streams. However, the output of the PRNG subsystem could be fed back as the uniformly random input probably. Of course you'd need a good seed to bootstrap the whole thing. [*] mathematics sense of the word: http://en.wikipedia.org/wiki/Extractor One good reason to do some randomness work outside the kernel is you can't do floating point in most Unix kernels, so if you're computing chi-square or some other statistic, you've either got to convert it to integer math or do it outside the kernel. On the down side, you've got scheduler delays adding to the latency of each request. I believe most common hardware RNGs produce data at fairly high rates, often I don't trust most of those sources to generate non-correlated bits at high rates. You know, the designs where they latch the output of oscillators based on some signal with random jitter is kind of like performing a modulo operation. Some information is thrown away in a many-to-one mapping, I wonder if you could gain something by modeling the jitter measurement before it is used to latch the output of the oscillator. It'd be like knowing g^x prior to modular reduction (mod n) in Diffie-Hellman. You could also just solve the problem you mention directly, and try to find a cheaper HWRNG design. I know people who have built them for a few dollars Terry Ritter has a lot of designs like this: http://www.ciphersbyritter.com/NOISE/NOISRC.HTM I'd like a system that is elegant and simple for harnessing, purifying, and securely stretching such values. By elegant and simple, what I mean is that it obviously has no weaknesses, as opposed to having no obvious weaknesses. -- http://www.lightconsulting.com/~travis/ -- We already have enough fast, insecure systems. -- Schneier Ferguson GPG fingerprint: 50A1 15C5 A9DE 23B9 ED98 C93E 38E9 204A 94C2 641B - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: EDP (entropy distribution protocol), userland PRNG design
I've been following this thread for a couple of weeks now, and so far virtually none of it makes any sense to me. Back on 10/12/2005 Travis H. wrote: I am thinking of making a userland entropy distribution system, so that expensive HWRNGs may be shared securely amongst several machines. What evidence is there that HRNGs are expensive? How many machines do you have? How many of them already have soundcards? How much entropy do they need (bits per second)? The obvious solution is to put a high-performance low-cost HRNG in each machine. http://www.av8n.com/turbid/ Is there some reason why this cannot be done? If so, please explain. Otherwise, this whole discussion seems like a futile exercise, i.e. trying to find the optimal way of doing the wrong thing. ]] ABSTRACT: We discuss the principles of a High-Entropy Randomness Generator (also called a True ]] Random Number Generator) that is suitable for a wide range of applications, including ]] cryptography, high-stakes gaming, and other highly adversarial applications. It harvests entropy ]] from physical processes, and uses that entropy efficiently. The hash saturation principle is used ]] to distill the data, resulting in virtually 100% entropy density. This is calculated, not ]] statistically estimated, and is provably correct under mild assumptions. In contrast to a ]] Pseudo-Random Number Generator, it has no internal state to worry about, and does not depend on ]] unprovable assumptions about “one-way functions”. We also describe a low-cost high-performance ]] implementation, using the computer’s audio I/O system. For details, see http://www.av8n.com/turbid/ Here's the algorithm from generation to use: 1) Entropy harvested from HWRNG. OK so far. 2) Entropy mixed with PRNG output to disguise any biases present in source. ... (Is XOR sufficent and desirable?) If it were a decent HRNG it would have this built in. XOR is not even remotely sufficient. 3) Entropy used as truly random input in an extractor to map somewhat random input (interrupt timing, memory contents, disk head settling times) into strongly random output. What's an extractor? What is needed is a compressor. 4) Entropy passed through OWF to occlude state of previous systems in this chain. A decent HRNG is stateless and does not need any one-way functions. 5?) Entropy ciphered with a randomly-generated key (taken from the previous step), rotated periodically. A decent HRNG does not need any such encipherment. Similarly, I also would like to use ID Quantique's HWRNG based on optics, Why? but their modules are sealed and opaque. What I want to do is explore what kind of assurances I can make about the output, based on assumptions about the attacker's ability to control, predict, or observe one of the sources. Such assurances are discussed at: http://www.av8n.com/turbid/ 5) Do it in a language not as prone to security-relevant errors as C and containing support for large numbers and bitstrings as first-class objects. turbid is already written in C++ for this reason. Strings and suchlike are part of the language, defined in the Standard Template Library. 1) Lack of standardization in the naming or semantics of kernel facilities, such as the names of devices in /dev. The semantics is just broken ... which is why turbid defines and implements /dev/hrandom with its own semantics. Optionally it can feed entropy to /dev/[u]random for the benefit of legacy applications under certain limited conditions. 2) Lack of support for sockets in the target language. Really not a problem with turbid. 3) The use of ioctls for interfacing to sources of entropy in the kernel. Really not a problem with turbid. 4) The use of tty devices to interface to HWRNGs Really not a problem with turbid. 5) Multiple clients petitioning the daemon for random bits at once. Really not a problem with turbid. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
