Funktionen i TrueCrypt kallas Plausible Deniability gör det möjligt att skapa gömda volymer (Deniable File System - DFS) avsedda att ej gå att detektera och därmed undvika problemet med att behöva uppge ett lösenord. TrueCrypts beskrivning av DFS är:

In case an adversary forces you to reveal your password, TrueCrypt provides and supports two kinds of plausible deniability:

1. Hidden volumes (for more information, see the section Hidden Volume).

2. It is impossible to identify a TrueCrypt volume. Until decrypted, a TrueCrypt volume appears to consist of nothing more than random data (it does not contain any kind of “signature”). Therefore, it is impossible to prove that a file, a partition or a device is a TrueCrypt volume or that it has been encrypted. However, note that for system encryption, the first drive track contains the (unencrypted) TrueCrypt Boot Loader, which can be easily identified as such (for more information, see the chapter System Encryption). In such cases, plausible deniability can be achieved by creating a hidden operating system (see the section Hidden Operating System).

TrueCrypt containers (file-hosted volumes) can have any file extension you like (for example, .raw, .iso, .img, .dat, .rnd, .tc) or they can have no file extension at all. TrueCrypt ignores file extensions. If you need plausible deniability, make sure your TrueCrypt volumes do not have the .tc file extension (this file extension is officially associated with TrueCrypt).

Nu har Bruce Schneier & Co attackerat DFS och kommer att presentera en artikel där dom visar att det i en normal datormiljö går att identifiera och komma åt en DFS-volym. Schneier & Co skriver:

We examine the security requirements for creating a Deniable File System (DFS), and the efficacy with which the TrueCrypt disk-encryption software meets those requirements. We find that the Windows Vista operating system itself, Microsoft Word, and Google Desktop all compromise the deniability of a TrueCrypt DFS.

While staged in the context of TrueCrypt, our research highlights several fundamental challenges to the creation and use of any DFS: even when the file system may be deniable in the pure, mathematical sense, we find that the environment surrounding that file system can undermine its deniability, as well as its contents. Finally, we suggest approaches for overcoming these challenges on modern operating systems like Windows.

Notera att det alltså inte är brister i TrueCrypts algoritmer, utan snarare svårigheten att skapa en DFS i ett datorsystem med OS och andra applikationer.

Enligt Dark Reading hävdar TrueCrypts skapare att den nyligen släppta 6.0-versionen fixar problemen, vilket dock Bruce Schneier tvivlar på.

På Light Blue Touchpaper, bloggen från säkerhetsguppen vid Cambridge Computer Laboratory har det dykt upp en intressant postning om ett nytt sätt att utföra lösenordsbaserad nyckelutbyte.

Lösenordsbaserad nyckelutbyte (Password Authenticated Key Exchange - PAKE) är en metod för att utbyta sessionsnycklar för säker kommunikation mellan parter baserad på lösenord (delad hemlighet). De två mest kända versionerna av PAKE är Encrypted Key Exchange - EKE och Simple Password Exponential Key Exchange - SPEKE.

Artikeln Password Authenticated Key Exchange by Juggling är skriven av Feng Hao och Peter Ryan. Artikelns sammanfattning förklarar nyttan med J-PAKE:

Password-Authenticated Key Exchange (PAKE) studies how to establish secure communication between two remote parties solely based on their shared password, without requiring a Public Key Infrastructure (PKI). Despite extensive research in the past decade, this problem remains unsolved. Patent has been one of the biggest brakes in deploying PAKE solutions in practice. Besides, even for the patented schemes like EKE and SPEKE, their security is only heuristic; researchers have reported some subtle but worrying security issues. In this paper, we propose to tackle this problem using an approach different from all past solutions.

Our protocol, Password Authenticated Key Exchange by Juggling (J-PAKE), achieves mutual authentication in two steps: first, two parties send ephemeral public keys to each other; second, they encrypt the shared password by juggling the public keys in a verifiable way. The first use of such a juggling technique was seen in solving the Dining Cryptographers problem in 2006. Here, we apply it to solve the PAKE problem, and show that the protocol is zero-knowledge as it reveals nothing except one-bit information: whether the supplied passwords at two sides are the same.

With clear advantages in security, our scheme has comparable efficiency to the EKE and SPEKE protocols.

(Jonglering med nycklar - om din nyckel heter som ditt husdjur…)

Artikeln innehåller en hel del referenser till koncept och metoder jag inte kände till innan, exempelvis Dining Cryptographers. (Det verkar pågå verksamhet på Wikipedia för att skriva om förklaringen av problemet - se den här och den här sidan.)

Implementationsmässigt verkar den nya metoden inte vara så hemsk. Författarna skriver:

Since our protocol involves several zero-knowledge proofs, one might concern about its cost. We now count the number of exponentiations in the protocol and evaluate its computational effciency..in our protocol, each party would need to perform 14 exponentiations in total – including 8 in the first step, 4 in the second step, and 2 in computing the session key.

To better assess the cost in real terms, we implement the protocol in Java on a 2.33-GHz laptop running Mac OS X. The modulus p is chosen 1024-bit and the subgroup order q 160-bit
…
The results demonstrate that the protocol – executed only once in a session – runs sufficiently fast. The total computation time is merely 0.075 sec. As compared to the time that the user keys in his password, this latency is negligible at the client.

However, the cost at the server may accumulate to be significant if requests are dealt with simultaneously. Therefore, the threat of Denial of Service (DoS) attacks still needs to be properly addressed in practical deployments.

Vad gäller säkerheten skriver författarna att:

EKE requires changing the protocol in its existing form for a secure implementation. As for a SPEKE, it has the drawback that an active attacker may test multiple passwords in one protocol execution. Furthermore, neither protocol – in the original form – accommodates short exponents securely. Finally, neither protocol is provably secure; formal security proofs seem unlikely without introducing new security assumptions or relaxing security requirements.

We choose to solve the PAKE problem using a different approach. The novelty of our design is that we encrypt the password by juggling the public keys in a way that can be verified. As a result, our scheme is provably secure, allows flexible use of short exponents, and strictly limits an active attacker to test only one password per protocol execution.

För ett tag sedan blev Java-koden till implementationen av J-PAKE tillgänglig. Jag har inte testat den själv. Intressant nog kallas den för JPAKE2, vilket skulle kunna betyda att det funnits en tidigare version av algoritmen som man av någon anledning inte var nöjd med.

Författarna har även skickat in J-PAKE som förslag till en framtida utökning av IEEE P1363.

När J-PAKE uppmärksammades på Cyptography-listan dök det upp referenser till en annan, ny PAKE-algoritm. Det finns en Internet Draft, EAP Authentication Using Only A Password som tydligen är under utvärdering av IEEE för den kommande WLAN-standarden 802.11s.

Bra och enkla och allmänt tillgängliga metoder för nyckelutbyte är klart intressant. Med två stycken nya, säkra och ej patenterade utan öppna algoritmer kanske PAKE kan få bättre spridning. Inte minst för inbyggda system är J-PAKE klart intressant.

Jag kunde i alla fall inte komma på något bättre och hackade lite Python nu på eftermiddagen. 176 rader senare inklusive kommentarer, filhuvud och testfall kan jag i alla fall köra några instruktioner:


js@sotis:/Users/js/tmp>./6502.py
MOS 6502: CPU initializing.
MOS 6502: Dumping memory from 100 to 111
100: ea
101: ea
102: ea
103: ea
104: ea
105: ea
106: ea
107: ea
108: ea
109: ea
10a: ea
10b: ea
10c: ea
10d: ea
10e: ea
10f: ea
110: 60
111: 0
MOS 6502: Running program from start address 100
MOS 6502: Executing NOP
MOS 6502: Executing NOP
MOS 6502: Executing NOP
MOS 6502: Executing NOP
MOS 6502: Executing NOP
MOS 6502: Executing NOP
MOS 6502: Executing NOP
MOS 6502: Executing NOP
MOS 6502: Executing NOP
MOS 6502: Executing NOP
MOS 6502: Executing NOP
MOS 6502: Executing NOP
MOS 6502: Executing NOP
MOS 6502: Executing NOP
MOS 6502: Executing NOP
MOS 6502: Executing NOP
MOS 6502: Executing RTS
Cycles executed: 34


(Japp, min emulator räknar bland annat även cykler. Har alltid velat ha den funktionen. Tänk vad många cykler man räknade i sin finniga ungdom när man kodade på C64:an.)

Det saknas en massa instruktioner och jag är inte säker på om jag verkligen skall ha en separat decode-funktion och en exekverings-funktion. Det blir väldigt mycket upprepning av if-elsif-elsif-else i de två funktionerna.

En intressant (nåja) observation är att min emulator, skriven i ett intepreterande språk, antagligen är flera gånger snabbare än den verkliga processorn. Dock inte lika snabb som den variant av 6502 vi byggde in i InformAsics VPN-chip, den går i upp till 33 MHz.

• Parallell exekvering på multicoreprocessorer eller på multiprocessorsystem. Prestandan skall enligt uppgift skala proportionellt med antalet cores eller processorer.
• Stöd för att skapa gömda, krypterade operativsystem (Windows Vista/XP/2008/2003).
• Stöd för att skapa gömda, krypterade volymer i Mac OS X och Linux.

På TrueCrypts webbplats finns även en skärmdump med lite prestandasiffror från en multicore-maskin:

Prestanda på en maskin med Intel® Core™ 2 Quad Q9450 2.66 GHz.”

Jag testade att använda tjänsten för att koda strängen:

Kryptoblog


Spammimic genererade texten:

Dear Friend , Especially for you - this cutting-edge announcement ! If you no longer wish to receive our publications simply reply with a Subject: of "REMOVE" and you will immediately be removed from our database! This mail is being sent in compliance with Senate bill 1622 , Title 6 , Section 301 ! This is NOT unsolicited bulk mail . Why work for somebody else when you can become rich within 28 weeks . Have you ever noticed most everyone has a cellphone & how many people you know are on the Internet . Well, now is your chance to capitalize on this ! WE will help YOU use credit cards on your website and turn your business into an E-BUSINESS ! You can begin at absolutely no cost to you . But don't believe us . Mr Jones of Massachusetts tried us and says "My only problem now is where to park all my cars" ! We are licensed to operate in all states ! We beseech you - act now . Sign up a friend and your friend will be rich too ! Thank-you for your serious consideration of our offer !


Jag testade även att lägga till ett a resp ett ö i slutet av Kryptoblog och fick följande förändringar:

Kryptoblog vs Kryptobloga:

> you . But don't believe us . Mr Ames who resides in
> Washington tried us and says "I was skeptical but it
> worked for me" ! We are licensed to operate in all


Kryptoblog vs Kryptoblogö:

> Dear E-Commerce professional ; This letter was specially
> selected to be sent to you . This is a one time mailing
> there is no need to request removal if you won't want
> any more . This mail is being sent in compliance with
> Senate bill 1625 ; Title 2 , Section 309 . This is
> not multi-level marketing . Why work for somebody else
> when you can become rich as few as 33 weeks . Have
> you ever noticed nobody is getting any younger & nobody
> is getting any younger . Well, now is your chance to
> capitalize on this ! We will help you increase customer
> response by 190% plus deliver goods right to the customer's
> doorstep . You are guaranteed to succeed because we
> take all the risk ! But don't believe us ! Mr Anderson
> who resides in Kentucky tried us and says "I've been
> poor and I've been rich - rich is better" ! We assure
> you that we operate within all applicable laws . We
> BESEECH you - act now ! Sign up a friend and you get
> half off . Thank-you for your serious consideration
> of our offer ! Dear Professional , This letter was
> specially selected to be sent to you . We will comply
> with all removal requests ! This mail is being sent
> in compliance with Senate bill 1916 , Title 4 ; Section
> 304 . This is not a get rich scheme . Why work for
> somebody else when you can become rich inside 57 days
> ! Have you ever noticed people love convenience and
> more people than ever are surfing the web . Well, now
> is your chance to capitalize on this . WE will help
> YOU turn your business into an E-BUSINESS and deliver
> goods right to the customer's doorstep ! You can begin
> at absolutely no cost to you . But don't believe us
> ! Prof Anderson of Idaho tried us and says "Now I'm
> rich, Rich, RICH" ! We are a BBB member in good standing
> ! For the sake of your family order now ! Sign up a
> friend and you'll get a discount of 60% . Cheers !


Dvs det finns inte en enkel koppling mellan antalet bokstäver i klartexten och i kryptotexten. En liten förändring i klartexten ger upphov till stora förändringar av kryptotexten. Vidare varierar även vilka ord som används, mellanslag, punktuation och andra tecken variera, så Spammimic verkar använda ganska månfa frihetsgrader för att koda. Dock verkar strängen This mail is being sent in compliance with Senate bill förekomma ofta, vilket skulle kunna användas för att leta efter kryptotexten.

Spammimic verkar generera en ganska besvärlig kodad text, och förhoppningsvis används ett vettigt krypto för att kryptera klartexten innan den kodas om till spamtext. Men frågan är hur bra Spammimic är. Är detta ett sett att kommunicera säkert, eller ett bra sätt att bli svartlistad och inte kunna kommunicera alls?

Boingboing rapporterar nu att NXP satt press på forskare vid Radboud University i Nijmegen, Holland för att stoppa publiceringen av sina forskningsresultat som visar ännu fler svagheter i MiFare. NXP har helt enkelt stämt forskarna och åberopar säkerhet som skäl att stoppa publiceringen.

Och självklart innebar detta att artikeln NXP försöker stoppa har smitit ut på nätet. Ett tag fanns artikeln på Wikileaks, men försvann. Däremot har den dykt upp både på Cryptome och på ArXiv.

Artikeln A Practical Attack on the MIFARE Classic beskriver enligt sammanfattninen:

The MIFARE Classic is the most widely used contactless smart card in the market. Its design and implementation details are kept secret by its manufacturer.

This paper studies the architecture of the card and the communication protocol between card and reader. Then it gives a practical, low-cost, attack that recovers secret information from the memory of the card.

Due to a weakness in the pseudo-random generator, we are able to recover the keystream generated by the CRYPTO1 stream cipher. We exploit the malleability of the stream cipher to read all memory blocks of the first sector of the card. Moreover, we are able to read any sector of the memory of the card, provided that we know one memory block within this sector. Finally, and perhaps more damaging, the same holds for modifying memory blocks.

Värt att notera att attacken sker över radiogränssnittet (RFID-standarden ISO 14443). Dvs det är inte så att man plockat isär ett MiFare-kort och attackerat chipet, utan försöker efterlikna ett troligt scenario där någon trådlöst försöker klona ett kort.

Artikeln är rejält matig och innehåller en pedagogisk och bra genomgång av hur MiFare Classic fungerar. Då det finns svenska användare av MiFare är det värt att upprepa artikelns rekommendationer:

For short term improvements we recommend not to use sector zero to store secret information. Configure key B as readable and store random information in it. Do not store sensitive information in the first 6 bytes of any sector. Use multiple sector authentications in one transaction to thwart attackers in an attempt to recover plaintext. This is only helpful when value block commands are not allowed. Value block commands are shorter than a read command and will enable a shift of the keystream.

Another possibility, that might be viable for some applications, is to employ another encryption scheme like AES in the backoffice, and store only encrypted information on the tags. To prevent unauthorized modification of a data block, an extra authentication on this data could be added. This authentication
is then verified in the backoffice.

Proper fraud detection mechanisms and extra security features in the backoffice are necessary to signal or even prevent the types of attacks described above. In general, the backoffice systems collecting and processing data that comes from the readers are a very important second line of defense.

On the long term these countermeasures will not be sufficient. The mifare Classic card has a closed design. Security by obscurity has shown several times that at some point the details of the system will be revealed compromising security. Therefore we recommend to migrate to more advanced cards with an open design architecture.

Forskarna har även gjort en fin film som visar hur deras attack går till. Om deras scanning är så snabb som filmen visar är det här riktigt skrämmande:

Vad skall man säga om NXPs agerande? Istället för att arbeta tillsammans med forskarna och exempelvis i samband med publiceringen ordna seminarier för sina kunder om hur de skall agera för att skydda sig och sina kunder lyckas NXP med att:

1. Reta upp forskarna och förstöra möjligheterna till samarbete
2. Garantera att artikeln och information om hur MiFare Classic skall attackeras kommer ut på ett okontrollerat sätt
3. Framstå som ett otrevligt, aggressivt och ett säkerhetsmässigt inkompetent företag

Tre dumheter på samma gång, det är nästan bättre än ett Kinderägg.

(Ett Mifare-Kinderägg. Öppna och bli överraskad av NXP…)

Slutligen noterar jag att BBC rapporterar att Londons lokaltrafik har problem med sitt Oyster card-system. Oklart om det har att göra med en attack mot CRYPTO1 dock.

Detta kom på maillistan FreeBSD Security. OpenSSL är ganska tydlig när det gäller användandet av osäkra versioner av OpenSSL-biblioteketet. Någon försökte uppdatera dns/bin95 på ett system med FreeBSD 6.3-STABLE och fick följande respons:


> config.status: creating include/isc/platform.h
> config.status: creating config.h
> WARNING WARNING WARNING WARNING WARNING WARNING WARNING WARNING WARNING WARNING
> WARNING WARNING WARNING WARNING WARNING WARNING WARNING WARNING WARNING WARNING
> WARNING WARNING
> WARNING Your OpenSSL crypto library may be vulnerable to WARNING
> WARNING one or more of the the following known security WARNING
> WARNING flaws: WARNING
> WARNING WARNING
> WARNING CAN-2002-0659, CAN-2006-4339, CVE-2006-2937 and WARNING
> WARNING CVE-2006-2940. WARNING
> WARNING WARNING
> WARNING It is recommended that you upgrade to OpenSSL WARNING
> WARNING version 0.9.8d/0.9.7l (or greater). WARNING
> WARNING WARNING
> WARNING You can disable this warning by specifying: WARNING
> WARNING WARNING
> WARNING --disable-openssl-version-check WARNING
> WARNING WARNING
> WARNING WARNING WARNING WARNING WARNING WARNING WARNING WARNING WARNING WARNING
> WARNING WARNING WARNING WARNING WARNING WARNING WARNING WARNING WARNING WARNING
> ===> Building for bind95-base-9.5.0.1


(Många varningar blir det.)

Borde vara svårt att missa att det är dags att uppdatera OpenSSL…

Artikeln Steganography of VoIP streams sammanfattning lyder:

In this paper, we circumscribe available steganographic techniques that can be used for creating covert channels for VoIP (Voice over Internet Protocol) streams.

Apart from characterizing existing steganographic methods we provide new insights by presenting two new techniques. First one is network steganography solution and exploits free/unused fields of the RTCP (Real-Time Control Protocol) and RTP (Real-Time Transport Protocol) protocols.

The second method provides hybrid storage-timing covert channel by utilizing delayed audio packets. The results of the experiment, that was performed, regardless of steganalysis, to estimate a total amount of data that can be covertly transferred in VoIP RTP stream during the typical call, are also included in this article.

Artikeln innehåller alltså en generell beskrivning av möjliga sätt att kommunicera med steganografi i en VoIP-kommunikation, en skattning av den bandbredd som går att dölja i en VoIP-ström samt två nya metoder för steganografi.

Av de två metoderna tycker jag den andra är mest intressant. Detta inte minst eftersom jag tidigare bloggat om en attack mot anonymiserad VoIP-kommunikation genom att märka VoIP-strömmen med distinkt varians mellan paketen. Här används väsentligen samma metod för att införa en steganografisk sidokanal.

Vi har precis sett att det går att utföra signalanalys på krypterad VoIP-trafik, och där lärdomen ser ut att vara att undvika CODEC:ar med variabel utbandbredd samt sända data i fixa blockstorlekar (om minst 128 bitar).

Här kommer alltså alternativa (eller komplementära) metoder där det intressanta inte går som röstkommunikation, utan det relevanta skickas i en sidokanal i RCTP och RTP alternativt som kontrollerad varians mellan paketen.

Tricket är kanske att sätta talsyntesen på att läsa upp några slumpmässigt valda Wikipedia-sidor. I denna babbelkommunikation skickas sedan (krypterad och integritetsskyddad) information gömd med steganografi.

IT-säkerhets- och kryptokapprustningen går vidare, en artikel i taget.

I slutet av maj släppte Apple ett dokument som beskriver säkerhetsmekanismerna i Mac OS X Leopard och hur mekanismerna går att konfigurera.

Dokumentet Mac OS X Security Configuration (PDF på 3.4 MByte) som enligt Apple provides instructions and recommendations for securing Mac OS X version 10.5 or later, and for maintaining a secure computer. är på 240+ fullmatade sidor.

Är du Leopard-användare och/eller ansvarar för att administrera maskiner med Leopard är detta ett dokument väl värd att läsa igenom.

För några veckor sedan hade Bruce Schneier en postning om en metod för att genomföra avlyssning av krypterad VoIP-trafik.

Bruce postning pekar på en artikel hos New Scientist som innehåller mer information. I artikeln berättas att forskare vid John Hopkins-universitetet på konferensen 2008 IEEE Symposium on Security and Privacy presenterat en artikel om hur de kan detektera ord och meningar även om kommunikationen är krypterad.

En av forskarna bakom artikeln är Charles V Wright.

På Charles webbplats finns två olika artiklar som beskriver olika aspekter av attacker mot krypterad VoIP-trafik. Artikeln Spot Me if You Can: Uncovering Spoken Phrases in Encrypted VoIP Conversations är den som New Scientist skriver om.

Båda artiklarna tar avstamp i att det i många digitala system för röstkommunikation används talkodare (speech encoder) som ger variabel bitlängd (VBR) på kodordet beroende på vad det är för ord som kodas. När sedan det kodade talet krypteras med ett strömkrypto som bevarar längden på kodordet upptår en varians i bitströmmen som är starkt korrelerad till orden i samtalet. Denna varians läcker alltså information om den krypterade kommunikationen, information som går att utnyttja.

Forskarna har fokuserat på CELP-baserade (Code-Exited Linear Prediction) talkodare, vilka ger upphov till variabel kod. CELB-baserade talkodare är mycket vanliga och återfinns bland annat i GSM, LTE (AMR-kodaren), flera “G.”-CODEC:ar (exempelvis G.728) och Speex. I sitt arbete har forskarna har använt Speex.

Forskarna har använt flera olika databaser med röster, databaser som används för att utveckla talkodare, för att upptäcka att det finns en korrelation mellan ord och kodat tal som är krypterat. En av de databaser som använts är TIMIT.

Ord och fraser har kodats med Speex och sedan analyserats utifrån varians. Forskarna har byggt upp en prediktor för varje fras de letar efter, Prediktorerna är Markov-modeller (HMM - Hidden Markov Model).

Prediktorerna har sedan fått titta på den krypterade bitströmmen och utvärdera om den överensstämmer med den varians som skall finnas för de fraser respektive prediktor är tränad på.

Eftersom CELP-kodare arbetar på korta fonem och frikativ blir mer komplicerade ord lättare att detektera. Ord som artificial och intelligence visade sig vara lätta att detektera. (Gissningsvis skulle Laplacetransformerade differentialekvationer sticka ut ordentligt..).

Resultatet är riktigt imponerande/skrämmande/överraskande:

Our results show that an eavesdropper who has access to neither recordings of the speaker’s voice nor even a single utterance of the target phrase, can identify instances of the phrase with average accuracy of 50%.

In some cases, accuracy can exceed 90%. Clearly, any system that is susceptible to such
attacks provides only a false sense of security to its users.

Frasen Young children should avoid exposure to contagious diseases predikterades perfekt i de tester som utförts. Forskarna fick dock en del falska träffar (false positives), men ju längre den sökta frasen var desto mindre falska fel erhölls.

I artikeln beskrivs även om försök att skydda kommunikationen genom att fylla ut den variabla bitströmmen till block om 128, 256 eller 512 bitar. Paddning visade sig fungera mycket bra. Nackelen med paddning är att det kostar i bandbredd. 512 bit stora block med Speex ger en extra bandbredd på drygt 30%. Paddning till 128 bit verkar vara minimum att använda, vilket ger en extra bandbredd på 16.5%.

Den andra, något äldre artikeln, Language Identification of Encrypted VoIP Traffic: Alejandra y Roberto or Alice and Bob? visar hur det går att identifiera vilket språk som talas i en krypterad VoIP-kommunikation. Detta utan orden i samtalet identifieras.

Författarna använder här variansen i samtalet i kombination med information om fördelning av ord, och speciellt bigram och trigram av ord för olika språk. Dessa fördelningar används för att skapa mönster eller prediktorer. Och det fungerar mycket bra. Forskarna skriver:

For instance, our 21-way classifier achieves 66% accuracy, almost a 14-fold improvement over random guessing. For 14 of the 21 languages, the accuracy is greater than 90%. We achieve an overall binary classification (e.g., “Is this a Spanish or English conversation?”) rate of 86.6%.

Även i den här artikeln har författarna undersökt hur väl det fungerar att försöka eliminera variansen genom att padda det kodade samtalet upp till fixa storlekar:

Padding to 128-bit blocks is largely ineffective because there is still sufficient granularity in the packet sizes that we can map them to basically to th esamet hree bins used by our improved classifier inSection4.2.

Even with192- or 256-bit blocks, where dimensionality reduction does not offer substantial improvement, the correct language can be identified on the first guess over 27% of the time — more than 5 times better than random guessing.

Sammantaget innebär resultaten i båda artiklarna alltså att även om det inte går avlyssna/tolka vad som sägs i ett samtal, går det att identifiera vilket språk som samtalet förs på!

Notera att det inte spelar någon som helst roll vilket krypto som används (så länge som variansen är bevarad). Kryptot kan vara hur bra som helst. Detta är ett exempel på en sidoattack och sättet att skydda sig mot detta är att inte tillåta någon varians, utan att kasta bandbredd på problemet och köra med en kodare som har en fix bandbredd ut. En sådan kodare är GSM Enhanced Full Rate, men även Speex innehåller en kodare med fix bandbredd.

En annan observation är att attackerna som presenteras i de två artiklarna är förhållandevis (förvånande) enkla. När väl prediktorerna har tagits fram krävs det lite beräkningskapacitet för att utföra attacken på strömmande data. Har man bara en kraftfull dator borde det inte vara något problem att titta på trafik realtid, iaf för ett begränsat antal samtal och begränsat antal fraser.

Jag hade dock valt att bygga en implementation av artiklarna med FPGA:er.

En trevlig FPGA från Altera.

Markovkodarna borde gå kanonfint att implementera som finita tillståndsmaskiner (FSM) med träningsmönster och tillstånd i block-RAM. En FSM-baserad HMM borde hinna med att hantera flera fraser (tidsmultiplex), och i en FPGA borde det gå att få in hundratals HMM:er.

Med hjälp av tekniken i den gamla artikeln detekterar man vilket språk som gäller. Utifrån den kunskapen laddar man in de träningsmönster som gäller i block-RAM. Sedan kan FPGA:erna leta efter intressanta mönster. Vid träff går man vidare och gör en mer detaljerad analys.

Så hade jag gjort.

På Charles Wrights webbplats finns en hel del andra intressanta artiklar vad gäller trafikanalys på krypterad trafik. Bland annat hur man kan identifiera och visualisera vilken typ av data (videoström, filöverföring, epost, webbsidor) som skickas i en krypterad ström. Mycket spännande om man är intresserad av att veta hur modern trafikanalys kan gå till, och vad man kan göra för att skydda sig.