Kryptoblog

För några veckor sedan dök det upp en blänkare på Cryptography om ett nytt verktyg - Tor VM.

Tor VM är en transparent proxy för att köra DNS och TCP-trafik genom anonymiseringsnätverket. Men i stället för att ansluta direkt till Tor körs trafiken via proxyn som snurrar i en virtiuell maskin. Vitsen med detta förfarande är enligt Tor VM:s sida:

The major advantage of running Tor VM is the protection you get from IP disclosure attacks that could leak your true IP address.

Du kan bygga Tor VM från källkoden, och det finns färdiga paket för att köra Tor VM fristående. Det finns dessutom färdiga ISO-filer som går att köra i VMware Player.

Tor VM påpekar dock att Tor är en anonymiserat nätverk, men att trafiken i sig inte är skyddad:

Tor VM will not protect you from leaking personal information while in use; please take caution in protecting your personal identity and information by not sending it across the Tor network. The use of encryption (HTTPS) whenever possible is highly recommended.

Enligt en säkerhetsrapport från FreeBSD-projektet finns det ett problem med slumptalsgeneratorn arc4random.

Säkerhetsrapporten FreeBSD-SA-08.11.arc4random beskriver problemet så här:

I. Background
arc4random(9) is a generic-purpose random number generator based on the key stream generator of the RC4 cipher. It is expected to be cryptographically strong, and used throughout the FreeBSD kernel for a variety of purposes, some of which rely on its cryptographic strength.

arc4random(9) is periodically reseeded with entropy from the FreeBSD kernel’s Yarrow random number generator, which gathers entropy from a variety of sources including hardware interrupts. During the boot process, additional entropy is provided to the Yarrow random number generator from userland, helping to ensure that adequate entropy is present for cryptographic purposes.

II. Problem Description
When the arc4random(9) random number generator is initialized, there may be inadequate entropy to meet the needs of kernel systems which rely on arc4random(9); and it may take up to 5 minutes before arc4random(9) is reseeded with secure entropy from the Yarrow random number generator.

III. Impact
All security-related kernel subsystems that rely on a quality random number generator are subject to a wide range of possible attacks for the 300 seconds after boot or until 64k of random data is consumed. The list includes:

* GEOM ELI providers with onetime keys. When a provider is configured in a way so that it gets attached at the same time during boot (e.g. it uses the rc subsystem to initialize) it might be possible for an attacker to recover the encrypted data.

* GEOM shsec providers. The GEOM shsec subsytem is used to split a shared secret between two providers so that it can be recovered when both of them are present. This is done by writing the random sequence to one of providers while appending the result of the random sequence on the other host to the original data. If the provider was created within the first 300 seconds after booting, it might be possible for an attacker to extract the original data with access to only one of the two providers between which the secret data is split.

* System processes started early after boot may receive predictable IDs.

* The 802.11 network stack uses arc4random(9) to generate initial vectors (IV) for WEP encryption when operating in client mode and WEP authentication challenges when operating in hostap mode, which may be insecure.

* The IPv4, IPv6 and TCP/UDP protocol implementations rely on a quality random number generator to produce unpredictable IP packet identifiers, initial TCP sequence numbers and outgoing port numbers. During the first 300 seconds after booting, it may be easier for an attacker to execute IP session hijacking, OS fingerprinting, idle scanning, or in some cases DNS cache poisoning and blind TCP data injection attacks.

* The kernel RPC code uses arc4random(9) to retrieve transaction identifiers, which might make RPC clients vulnerable to hijacking

IV. Workaround
No workaround is available for affected systems.

V. Solution
NOTE WELL: Any GEOM shsec providers which were created or written to
during the first 300 seconds after booting should be re-created after
applying this security update.

Perform one of the following:
1) Upgrade your vulnerable system to 6-STABLE, or 7-STABLE, or to the RELENG_7_0, or RELENG_6_3 security branch dated after the correction date.

2) To patch your present system:
The following patches have been verified to apply to FreeBSD 6.3 and 7.0 systems.

a) Download the relevant patch from the location below, and verify the detached PGP signature using your PGP utility.

[FreeBSD 7.x]
# fetch http://security.FreeBSD.org/patches/SA-08:11/arc4random.patch
# fetch http://security.FreeBSD.org/patches/SA-08:11/arc4random.patch.asc

[FreeBSD 6.x]
# fetch http://security.FreeBSD.org/patches/SA-08:11/arc4random6x.patch
# fetch http://security.FreeBSD.org/patches/SA-08:11/arc4random6x.patch.asc

b) Apply the patch.

# cd /usr/src
# patch < /path/to/patch

c) Recompile your kernel as described in
and reboot the system.

Kör du FreeBSD, och speciellt om du använder GEOM och GBDE bör du patcha eller uppgradera ditt system (om du inte redan gjort det).

EE Times rapporterar att Green Hills Software har fått sitt operativsystem Integrity certifierat enligt Common Criteria-nivån EAL 6+.

EAL6+ är den högsta EAL-nivån som hittills uppnåtts av ett operativsystem och är en innebär enligt Green Hills VS bland annat att:

EAL 4 means essentially you’ve documented the system, but no-one has looked at your source code and has not undergone any attempts to break into it,” said Dan O’Dowd, founder and chief executive officer of Green Hills Software. “But when you go to EAL6+, it requires formal mathematical proof that the system is secure.”

In this case, the government hired,”a bunch of Ph.Ds” to write formal proofs and evaluate the code and check code for correctness. “This is the first time anyone has proven that an operating system is secure,” he said.

Att USAs försvar varit inblandat är tydligt. Enligt artikeln var det NSA som beställde certifieringen. Intressant nog är det dessutom (återigen enligt artikeln) organisationen National Information Assurance Partnership (NIAP), som certifierat Integrity, en organisation som drivs av… NSA.

EAL6+-certifikatet för Integrity från NIAP.

Drivkraften bakom certifieringen är att säkerkt kunna köra flera applikationer på samma datorplattform. Artikeln förklarar:

Today, various levels of security are achieved using multiple computers on a desk — one for regular Internet access and others for security levels ranging from confidential to top secret. This results in up to four systems on a single desk, causing system cost, IT support costs, power consumption and desk space issues. Similarly, humvees in the field need multiple systems.

Det finns faktiskt utrustning certifierad enligt den högsta EAL-nivån, EAL-7. Närmare bestämt Tenix Data Diode Device, en LED-baserad transmissionsutrustning för att koppla samman nät över kortare avstånd. Så här ser den ut:

Det som inte klart framgår är hur mycket det kostade att certifiera Integrity enligt EAL-6+, men på Wikipedia finns en del skattningar för kostnader för lägre EAL-nivåer. I artikeln kan man dessutom utläsa att processen tog ungefär fyra år.

Vill du ha ett riktigt, riktigt säkert OS (eller en lysdiodburk) skall du kanske titta närmare på de här produkterna.

I somras bloggade jag om en ny metod för lösenordsbaserat nyckelutbyte kallad J-PAKE. J-PAKE erbjuder flera ördelar jämfört med andra metoder. Dock har det fram till nu bara funnits en Java-implementation.

Googles kryptoninja och OpenSSL-utvecklaren Ben Laurie har implementerat nyckelutbytesalgoritmen J-PAKE i C som en en modul i OpenSSL. Detta gör att den som vill testa J-PAKE (givet att man har den nya modulen) nu kan använda J-PAKE direkt i OpenSSL. Ben skriver:

So, this weekend I implemented J-PAKE as a proper OpenSSL module. Plus support in s_server and s_client. You can test it like this:

openssl s_server -jpake secret
openssl s_client -jpake secret

If you want to use two different machines, as required by Mr. Churlish, then you’ll need to use the -connect option to s_client.

If you want to use it yourself, you can find example code in apps/apps.c. Look for the functions jpake_client_auth() and jpake_server_auth().

Ben Laurie har även en utmärkt blogg väl värd att läsa om man är intresserad av krypto och IT-säkerhet.

Ben Laurie från hans sida med publikationer på Google Research.

Fyodor postade i går att version 4.75 av nmap nu finns tillgänglig för nedladdning. En av de 100 nyheterna i den nya versionen av allas favoritportscanner är att nmap nu kan rita grafer över nättopologin:

Bara att tanka ner och börja leka.

I slutet av augusti släpptes den tredje och sista betaversionen av Python 2.6. I samband med detta publicerades ett dokument som beskriver nyheterna i Python 2.6.

Bland alla förändringar avsedda att bereda vägen för Python 3.0, with-satsen, ett nytt I/O-bibliotek och en massa andra spännande saker hittade jag ett par säkerhetsrelaterade saker värda att uppmärksamma.

En förändring jag ser fram emot är den nya modulen ssl. Tidigare versioner av Python har haft ett ganska rudimentärt stöd för SSL (vilket finns i socket-modulen). Men Python 2.6 inkluderar en helt ny modul som bygger på OpenSSL. Den nya modulen exponerar väsentligen hela OpenSSLs funktionalitet för Pythonutvecklare.

Jag har tidigare försökt bygga applikationer som processar och analyserar certifikat, men gett upp på grund av bristande stöd. Nu är det snart dags att göra ett nytt försök. Titta i dokumentationen till ssl-modulen för mer information.

Den andra nyheten var mer av en överraskning. Beta tre av Python 2.6 introducerar ett nytt sätt att hantera regulära uttryck där re-modulen (som hanterar regulära uttryck) nu är en separat, specialanpassad virtuell maskin. Poängen med detta är att regulära uttryck som leder till patologiska beteenden inte riskerar att skada Pythons egen VM. Den nya re-implementationen inkluderar även en ny regex-verifierare.

Den nya implementationen har utvecklats av Google för Google App Engine och ges nu tillbaka till Python som Apache-licensierad kod. Här finns mer information om detta.

Enligt den officiella tidplanen (PEP 361) släpps den officiella versionen av Python 2.den första oktober.

Jag har precis lagt upp en sida med mitt sommarhack MOS6502. MOS6502 är en enkel, objektorienterad emulator av den gamla processorn MOS 6502 skriven i Python.

Processormodelln inkluderar i dag alla API-synliga register, flaggor och pekare. Dock finns det ingen egentlig funktionalitet för stack och interrupt. Vidare är inte de mer ortodoxa instruktionspekar, och adressberäkningarna i MOS 6502 med.

Däremot finns det stöd för att räkna cykler och instruktioner samt stega processorn en instruktion i taget. Vidare kan processorn dumpa valfri del av sitt minne. Tanken är att detta skall underlätta profilering och debuggning av assemblerprogram.

MOS6502 klarar i dagsläget av att exekvera en delmängd av alla instruktioner, och av dessa inte alla adesseringsmoder. Dock klarar den i alla fall av att köra en implementation av PRNG-delen av strömkryptot RC4:

js@sotis:>time ./rc4_MOS6502.py
Key byte 0: 2
Key byte 100000: 34
Key byte 200000: 27
Key byte 300000: ba
Key byte 400000: 56
Key byte 500000: ac
Key byte 600000: b
Key byte 700000: 9c
Key byte 800000: 6b
Key byte 900000: 20
Cycles executed: 80000000
i_ptr = 40
j_ptr = 81
acc_reg = 8a
x_reg = 8a
y_reg = 8e
carry = 0
95.658u 0.103s 1:35.97 99.7% 0+0k 0+16io 0pf+0w


Körningen ovan är från ett exempelprogram som kör PRNG-delen av RC4 en miljon gånger. Assemblerkoden (som INTE är optimerad) tar 80 cykler per varv. Som synes tar körningen nästan 100 sekunder på min MacBook. Dvs jag får nästan 1 MHz(!) i klockfrekvens och drygt 10 kByte/s i kryptoprestanda. Inte snabbt, men samtidigt inte illa av en emulerad processor som körs i en emulerad miljö (Python VM).

RC4-exemplet finns med i den release som finns att tanka ner på emulatorns sida. Jag tar väldigt gärna emot kommentarer, buggrapporter, patchar och tips för att utveckla emulatorn vidare.

Google har släppt ett verktyg för att hantera nycklar kallat KeyCzar.

Nyckelhantering är en av de riktigt svåra momenten när det kommer till kommunikationssäkerhet (både design och implementation). Tanken med KeyCzar är att underlätta för applikationsutvecklare genom att tillhandahålla ett bibliotek som sköter nyckelhanteringen på ett bra sätt. Några av funktionerna som KeyCzar erbjuder är:

• Nyckelrotation och versionshantering av nycklar inkl att återkalla (döda) nycklar.
• Implementation av bra algoritmer och vettiga nyckellängder.
• Generering av initialvektorer (IV) och signaturer.
• Stöd för att kryptera/dekryptera och verifiera.
• Stöd för applikationer skrivna i Java eller Python.

Bra algoritmer och vettiga längder är vad Google själva skriver, och det låter fluffigt. Men tittar man i den utmärkta designdokumentationen för KeyCzar ser man att de använder 1024-bit DSA med SHA-1 för signering. KeyCzar stödjer även RSA OAEP med 512-2048 bitar för publik kryptering och RSA SHA-1 med 512-2048 bitar för publik signering. Vidare används AES 128, 192 och 256 med CBC-mod för symmetrisk kryptering och HMAC med SHA-1 och 256 bit nyckel för symmetrisk signering.

KeyCzar genererar X.509-fält och allt annat pill som brukar ställa till det vid implementationer. Allt du behöver göra är att skapa ett KeyCzar-objekt och sedan lita på att KeyCzar gör rätt.

Enligt Google har KeyCzar ett enkelt API. Om det är enkelt eller ej är en bedömningsfråga, men jag hade iaf inga problem att på några få minuter ladda ner, installera och sparka igång KeyCzar i en testapplikation. Google påpekar även att:

Keyczar sacrifices some flexibility in favor of safety and ease of use. Protecting developers from mistakes and handling details for them may also hide useful underlying features. Please see the NonGoals wiki page for a description of things that Keyczar is not.

Av de saker KeyCzar inte är listar Google bla att det inte är en ersättning för OpenSSL eller vara en komplett PKI-lösning.

KeyCzar började som Ben Lauris startprojekt när han började på Google. Projektet togs sedan över av Googles säkerhetsteam som nu ansvarar för utvecklingen.

KeyCzar är Apache 2.0-licensierad och finns att ladda ner (Java, Python). Här finns Java-dokumentationen och här finns Python-dokumentationen. Slutligen finns det även ett diskussionforum (en grupp) för KeyCzar. Än så länge är det dock med KeyCzar-skaparna som postat i gruppen.

Jag tycker att KeyCzar är ett bra initiativ av Google och om det fungerer som det står i dokumentationen och det inte finns en massa fel i KeyCzar är det ett bra tillskott i verktygslådan för att bygga IT-säkerhet.

En fundering: I USA är det populärt att utnämna Tsarer för olika saker. Ex finns det en cybersäkerhets-tsar. Med tanke på alla starka signaler och liknande begrepp och koncept som verkar lånas in friskt, när får Sverige sin första tsar-någonting? Eller blir den svenska varianten hertig eller baron?)

Fil- och diskkrypteringsverktyget TrueCrypt har släppts i en ny stor version. Version 6.0 introducerar bland annat:

• 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.”

Fick tips om en skruvad steganografitjänst kallad Spammimic.

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?