* Original: FROM..... A Grudko
Shock horror - Dutch Intel. leaking to the Israelis.
<http://www.fnl.nl/ct/archief2002/ct2002-12/aftappen.htm>http://www.fnl.nl/ct/archief2002/ct2002-12/aftappen.htm
Paul Wouters, Patrick Smits
According to anonymous sources within the Dutch intelligence
community, all tapping equipment of the Dutch intelligence services
and half the tapping equipment of the national police force, is
insecure and is leaking information to Israel. How difficult is it to
make a back-door in the Dutch Transport of Intercepted IP Traffic[1]
system? The discussion focuses on the tapping installations for
telephony and internet delivered to the government in the last few
years by the Israeli company Verint[2].
This company was called Comverse-Infosys[3] until half a year ago, but
was quickly renamed when the FBI started several investigations
against it and arrested some of its employees in the US on suspicion
of espionage. (See pulled FoxNews stories, Politech, Cryptome or
Google).
People within the Dutch government got worried too. Especially because
they had been warned as early as 1998 about the possible back-doors in
the tapping equipment. The ex-ministers of interior ("Binnenlandse
Zaken"), Peper and de Vries, could not comment. The minister of
Justice at the time, Korthals Altes, was asked to report to parliament
in December 2001, where he stated that the security measures meet the
required level and that an investigation would be started if this,
after all, was not the case. No investigation followed.
In April 2002, Kolkert, procecutor in-chief of the Court of Appeals in
Den Bosch, demanded clarification in a letter sent to Stein, the state
prosecutor ("landelijk officier van justitie") and responsible for
interception matters. Stein stated that there are no problems.
On august 24 the project leader of the National Interception
Organisation ("Landelijk Interceptie Orgaan", LIO) J.Steeg announced
that he plans to check the tapping rooms for backdoors. However, when
the equipment was bought from the Israelis, it was agreed that no one
except Comverse personnel was authorized to touch the systems,
according to the insider of the AIVD (formerly BVD), the Dutch
intelligence organization that spoke to the EO radioprogram De
Ochtenden[4]. Source code would never be available to anyone.
Finally, on October 10th, the Council of Chiefs of Police ("raad van
hoofdcommisarissen") sent a confidential letter to the vendors of
tapping equipment for ISPs and telcos expressing its concern about the
situation in the US.
All of this came after questions were raised publicly in the trial
against Baybasin, co-founder of the Kurd parliament in exile, about
the possible leaks in the Dutch tapping room as well as manipulation
of the collected evidence[4b]. Baybasin was recently sentenced to
life-long imprisonment for his connections to assassinations,
kidnappings and heroine transports. His lawyers called in experts to
question them about the possibility that Israel had laid hands on
information tapped by the Dutch. The lawyers claim that Israeli then
forwarded the information to the Turkish secret service[5]. Baybasin
recently told the media about the Turkish government's involvement
with crime syndicates.
c't magazine warned about the blackbox problem in its June 2001
issue[6]. Opentap[7] gave similar warnings on the hacker conference
HAL2001[8] in August of 2001 and at the Chaos Computer Club (CCC)[9]
in December 2001 with a presentation on lawful interception in the
Netherlands[10].
Hebrew as crypto
The insiders at the AIVD and the tapping room were interviewed by the
radio program of the EO[11]. According to them, the Dutch government
and Comverse have a gentlemen's agreement that the Dutch government
would get the Comverse systems for a very reduced price and in
exchange the Israelis would get full access to all tapped
information. The systems still ended up being more expensive than
rejected competitors' quotes. The Comverse maintenance contract alone
apparently costs more then the installation itself, according to the
anonymous sources. Since the leaks seem to be disguised as
maintenance, one could say that the Dutch government is actually
paying the cost of foreign intelligence against the Dutch state.
Israeli Comverse employees apparently show up in the tapping rooms on
a very regular basis for maintenance, since no Dutch are allowed to
touch the equipment. The radio program further stated that the
maintenance is done using their own Hebrew keyboards and
language. They leave the tapping rooms with filled MO-discs and no-one
from the Dutch government has any idea what the Comverse people are
doing. To make things yet worse, Comverse can dial-in to the tapping
room equipment at all times.
The possible criminal nature of Comverse and their overpricing are not
the only problems. A comparison of the Comverse tapping records with
billing records of KPN, the largest Dutch telco, shows that 20% of the
calls that should be tapped, are not tapped at all. The Dutch
government still keeps buying Comverse equipment.
On November 26, a day after the EO radio program was broadcasted,
three political parties, D'66, GroenLinks and SP asked questions to
the government in parliamant. The current minister of interior,
Remkens, answered that the chance of the tapping rooms leaking
information is small, but not zero. He further claimed that the
Comverse employees were given the most strict screening by the Dutch
intelligence agency AIVD, and that they are never allowed to work
without supervision. Comverse was chosen based on its
price-performance results, the minister said.
Hacking the system?
In an interview with 2Vandaag[12], a daily Dutch television news
program, defense specialist and LPF party leader Herben believes that
there is enough cryptography know-how available in the Netherlands to
hack the systems, if Comverse does not assist in the evaluation
process. Apparently, Herben hasn't thought about the intrusion
detection system that has undoubtedly been installed in these tapping
systems by Comverse. He also seems to forget (as did Remkes) that
these systems work in Hebrew. On top of it, proving the inner workings
of the machines to be correct and safe is anything but a trivial task.
The capacity of the MO-discs and the bandwidth of the dial-up
facilities is not enough to copy a lot of Internet traffic or entire
telephone conversations. A Comverse employee would have to swap disks
so often, that he would have to use the tapping room as a hotel. So,
assuming that there is no (illegal) high-speed Internet connection
between the tapping room and the Israeli embassy, what the Comvers
staff can do at the most on these visits is to copy a list of who
talks to whom, and the cryptographic keys that are used to secure the
tapping communications. Therefore, the Israelis don't need to copy
entire phone conversations or all Internet traffic of a user from
within the tapping room, but can simply monitor the encrypted traffic
that is sent to the tapping room. Having the cryptographic key to the
data, they then decrypt it at their leisure. If any nation has the
technical skills and knowledge to pull this off, it is Israel.
The experts
We explained the situation to two cryptography experts: Niels
Provos[13] of the OpenBSD team and author of various crypto software
such as Outguess[14], a program to detect steganographic content, and
Michael Richardson[15] of the FreeSwan Project, the IPsec
implementation of Linux. We posed the hypothesis of the insecure
tapping room and asked whether it would be possible for the Israelis
to get a hold of our taps. Provos explains that a very important part
of strong cryptography is a good random source. Without a proper
random generator, or worse, with a intentionally crippled random
generator, the resulting ciphertext becomes trivial to break. Even if
Comverse would let experts have a look at the source code, if there is
one single unknown chip involved with the random generation, such as a
hardware accelerator chip, all bets are off. Provos suggests to use
only off-the-shelf PC hardware. If you can trust the hardware and you
have access to the source code, then it should theoretically be
possible to verify the system. This, however, can just not be done
without the source code, according to Provos.
One possible undetectable scheme could be to use a set of truly
random, but pre-calculated keys. Only those who know the
pre-calculated set, Comverse in this case, could break the cipher,
which would become a sort of one-time pad for Comverse only. Provos
also pointed us to the work of Adam Young en Moti Yung, who have
written a few papers on what they dubbed, kleptography[16], the art of
secretly stealing the cryptographic key from the ciphertext stream
itself. Their research showed it is impossible for third parties to
detect whether any given ciphertext is secretly leaking key material.
An overview of TIIT
The Dutch tapping protocol, Transport of Intercepted IP Traffic[1] is
used for the communication between the tapping machine at the ISP, and
the Dutch government. The suspect who is using the Internet generates
IP traffic that is copied by a special sniffer machine, called S1. The
S1 then encrypts the traffic with an RC4 (or AES) key supplied (and
generated) by the Dutch tapping room, and sends the encrypted traffic
to the S2, the ISP's collector machine. The collector sets up an
encrypted connection, using SSL or IPsec to the government collector
machine, the T2. This will normally happen over the internet
itself. The T1 then sends the encrypted information onwards to one
more agencies, who all have their own T2 for receiving the encrypted
traffic. The T2's have the key to decrypt the gathered data into the
original plaintext, as it was captured by the ISP.
Both the SSL and IPsec protocol, which are part of the encryption
scheme used by the Dutch tapping specification (TIIT), contain parts
where one has to "fill" packets with random data. It is impossible to
see whether this data is truly random, or contains a secret
message. This means that no-one needs to go to the tapping room to
fetch the key material. According to Provos, the keys can just be
sneaked into the encrypted tap itself. Richardson agrees with this
view. There has even been a software implementation of this in the
past. The TIS-client implemented this feature as "Government Access to
Session Keys method". There are even rumors that the ciphers SHA1 and
DSS, both NSA ciphers, leak key information on purpose, with only the
NSA knowing how to retrieve it. Richardson claims that it is easy to
use weak key material. And there are other dangers as well. Because
RC4 is based on XOR, using the same key twice is enough to crack the
code. RC4 is used for the inner encryption of user data in the TIIT,
since the final AES candidate wasn't known at the time when the
protocol was set. But this RC4 encrpytion is packaged in another layer
of encryption, SSL or IPsec. That layer needs to be broken as well.
Richardson takes IPsec as example. Imagine that we need to leak an RC4
key and an IPsec key. For RC4, only the first 128bits are
relevant. For IPsec 3DES is often used, which means another two times
56bits. Each IPsec packet has an IV of 64 bits. This IV is random
filling to ensure that there will never be two identical packets
encrypted with the same key, a deadly sin in the world of
cryptography. So this makes it possible to hide 64bits in each IPsec
packet. Theoretically, after two packets you have leaked the RC4 key,
and after another two you have the 3DES key too, although Richardson
says that if such a scheme is used, it is very likely that the leaking
would take place a bit slower, so it can be covered up. For example,
the 64 bits can be divided in four parts of 16 bits hidden in the
first 20 bits of four IV's. 16 bits of actual key material and four
bits to point to the position of those bits in the key. That means
that about 16 IPsec packets are needed to leak the entire
key. According to Richardson, that would leave plenty of randomness in
the IV to make this leakage invisible.
Due to the overhead of IPsec and of the TIIT, this means the tapped
user needs to cause even less packets for this to happen. In other
words, reading a few lines of email or looking at a single webpage, is
more then enough to leak all key information.
Weis and Lucks showed that the use of the IV isn't even needed, and
presented their paper All your keybits ...[17] at SANE2002[18] that
mathematic proves that blackbox cryptography is fundamentally insecure
and that leaking key material cannot be detected in any way.
Conclusion
Without the cooperation of Comverse, is it not possible to determine
whether the Dutch tapping systems contain backdoors or not. Worse,
even if Comverse would appear to cooperate, there is no way to detect
a possible double-cross. Key information can leak quickly and
undetectable and the only way to prevent that is by having full
control over both the hardware and the software involved.
In mid December, the parliament will discuss the annual report of the
AIVD, but it seems unlikely that the public will ever find out what
really happened. Remkes only wants to talk about these matters behind
closed doors. De Graaf, party leader of D'66, said he finds the risk
of possible manipulation of the tapping rooms "pretty serious", but
cannot give more public statements, since he was a member of the
watchdog commission that oversees the intelligence service AIVD, and
therefore has inside sensitive knowledge.
Remkes claims he didn't know about the dangers. Apparently, he was the
last one that didn't know; Comverse and blackbox cryptography have
been under heavy fire for years.
Literature
[1]
<http://www.opentap.org/documents/TIIT-v1.0.0.pdf>http://www.opentap.org/documents/TIIT-v1.0.0.pdf
[2] http://www.verintsystems.com/
[3] <http://www.cominfosys.com/>http://www.cominfosys.com/
[4] http://www.eo.nl/home/html/news.jsp?number=3209417
[4b]
<http://www.volkskrant.nl/binnenland/8761030113615.html>http://www.volkskrant.nl/binnenland/8761030113615.html
[5] http://www.groene.nl/2002/0225/rz_tappen.html
[6]
<http://www.fnl.nl/ct-nl/archief2001/ct2001-06/ct200106032033.htm>http://www.fnl.nl/ct-nl/archief2001/ct2001-06/ct200106032033.htm
[7] http://www.opentap.org/
[8] <http://www.hal2001.nl/>http://www.hal2001.nl/
[9] http://www.ccc.de/
[10] <http://www.opentap.org/ccc/>http://www.opentap.org/ccc/
[11] http://cgi.omroep.nl/cgi-bin/streams?/eo/redactie/radio/r1022511c.rm
[12]
<http://cgi.omroep.nl/cgi-bin/streams?/eo/2vandaag/2vandaag_aftappen.rm>http://cgi.omroep.nl/cgi-bin/streams?/eo/2vandaag/2vandaag_aftappen.<http://cgi.omroep.nl/cgi-bin/streams?/eo/2vandaag/2vandaag_aftappen.rm>rm
[13] http://www.citi.umich.edu/u/provos
[14] <http://www.outguess.org/>http://www.outguess.org/
[15] http://www.sandelman.ottawa.on.ca
[16]
<http://home.bip.net/laszlob/cryptoag/kleptography.htm>http://home.bip.net/laszlob/cryptoag/kleptography<http://home.bip.net/laszlob/cryptoag/kleptography.htm>.htm
[17] http://www.nluug.nl/events/sane2002/papers/WeisLucksAllYourKeybit.ps
[18] <http://www.nluug.nl/events/sane2002/>http://www.nluug.nl/events/sane2002/
Marcus Didius Falco (falco_marcus_didius@yahoo.co.uk)