Då Daniel var lättövertalad att installera OTR och jag inte vill missa ett tillfälle att tipsa vem som än råkar läsa det här - information om off-the-record och installeringsinstruktion.

Åter till pgp/gpg. Tecknen i rubriken - 210ED3E0 - är min publika nyckel och den kan hämtas från pool.sks-keyservers.net alternativt, för er som föredrar att lägga till nyckel via urklipp så är det bara kopiera nedanstående.

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.4.7 (MingW32)

mQGiBEhVCB8RBADIYHjgWzkqylcq25

In un post precendente ho parlato di un estensione di Firefox che permette di crittare velocemente le mail di Gmail.

Enigmail è una semplice interfaccia tra OpenPGP e Mozilla Thunderbird e Seamonkey che aumenta esponenzialmente la sicurezza della nostra casella di posta. Integra i nuovi standard OpenPGP proposti da GnuPG.

Con questa estensione inviare e ricevere email con una firma digitale diventa facile!

Al primo avvio un semplice setup guiderà l'utente alla configurazione. Inoltre sul sito c'è una vasta documentazione per ogni sorta di problema. Nel caso ci fossero ulteriori complicazioni viene messa a disposizione una mailing list.

Alcuni screenshot qui :D

Wer mehr über das Thema Anonymisierung und Verschlüsselung nachlesen will, sollte sich im Wiki des Arbeitskreises Vorratsdatenspeicherung (AK Vorrat) informieren, welche Möglichkeiten er/sie hat, dem Präventivstaat mit seinem Datenhunger ein Schnäppchen zu schlagen, Stichwort: Ziviler Ungehorsam.

Given the above, I was surprised at what was in the affidavit. I
know there are several assumptions; the most glaring is that the
defendants actually used the PGP implementation in the Hushmail
system. The assumed response to a legal request for emails would
be the data stored on the server, which should be just PGP and
headers. The affidavit does not state that crackers or keyloggers
were used or that the passphrase was obtained from the users.
Given the rest of the detail, it seems like these important actions
would have been listed if they were used.

I wanted to know the collective opinion on how the contents of the
emails could then be made known to the DEA without a glaring hole
in the implementation or administration of Hushmail, either of
which would be important but disappointing to hear about.

rearden

On Thu, 01 Nov 2007 16:52:28 -0400 Jon Callas <jon@callas.org>
wrote:
>On Nov 1, 2007, at 10:49 AM, John Levine wrote:
>
>>> Since email between hushmail accounts is generally PGPed.
>(That is
>>> the point, right?)
>>
>> Hushmail is actually kind of a scam. In its normal
>configuration,
>> it's in effect just webmail with an HTTPS connection and a long
>> password. It will generate and verify PGP signatures and
>encryption
>> for mail it sends and receives, but they generate and maintain
>their
>> users' PGP keys.
>>
>> There's a Java applet that's supposed to do end to end
>encryption, but
>> since it's with the same key that Hushmail knows, what's the
>point?
>>
>
>I'm sorry, but that's a slur. Hushmail is not a scam. They do a
>very
>good job of explaining what they do, what they cannot do, and
>against
>which threats they protect. You may quibble all you want with its
>
>*effectiveness* but they are not a scam. A scam is being
>dishonest.
>
>You also mischaracterize the Hushmail system. The "classic"
>Hushmail
>does not generate the keys, and while it holds them, they're
>encrypted. The secrets Hushmail holds are as secure as the end
>user's
>operational security.
>
>I know what you're going to say next. People pick bad passphrases,
>
>etc. Yes, you're right. That is not being a scam.
>
>They have another system that is more web-service oriented, and
>they
>explain it on their web site far better than I could. It has
>further
>limitations in security but with increased usability. It is also
>not
>a scam.
>
> Jon
>
>-------------------------------------------------------------------
>--
>The Cryptography Mailing List
>Unsubscribe by sending "unsubscribe cryptography" to
>majordomo@metzdowd.com

--
Save hundreds on Technical School - Click here.
http://tagline.hushmail.com/fc/Ioyw6h4fRTdts2rXzvypA08i4x4ZY17uNW0IOfxYNnLUwGHrYCe6DW/

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com

A Rootkit is some sort of malware. Depending on whom you ask or enlist it is a piece of software running on someone's computer -- preferably with an Internet connection -- without the user or even administrator knowing. I understand the definition itself so that this program does not have to be hiding itself in the memory and/or on the hard drive from detection software but it may (regardless of the, to my knowledge and despite Joanna's work, unanswered question if potentially it can do so at all). Rootkits like any other malware have to be transferred to the target computer in some way or another and are -- the hiding once like any other -- detectable in this non-executed state (via digital signature for example). Ones primed, i.e. executed, the code becomes a process in the computer's memory and tries to hide itself with various methods in memory and hard drives (potentially also MBR or even BIOS, but as far as I read/heard non have been reported so far).

Another factor of Rootkits is that they most often start with a small subset of code/features/routines and, ones residing in memory, recruit more and more features via the computer's net link through a so-called back door. The back door part is why the differentiation from Trojan Horses is blurry. I'd say the Trojan Horse technique is only one of many features of such a Rootkit but that doesn't make it a Trojan Horse since it's not all it can do.

One other of the many possible features, and first shown by the before named Bluepill, is to become a hypervisor (think of it as a sandbox for OSs) like Xen (virtual machines like VMware, Qemu/VirtualBox work differently). The fancy bit about bluepill's method is that, while active, the OS' kernel is virtualized, i.e. becomes a guest OS from being host OS before; Microsoft Vista kernel here. It's done by forcing to swap kernel parts to pagefile.sys which than are modified on disc -- no Vista kernel protection -- and loaded back to memory. Let me point out: On-the-fly, no reboot or BIOS or MBR modification necessary! That means that the malware runs below the OS or, rephrased the other way around, the real OS runs on top of the malware.

From Darkreading:

The new Blue Pill comes with support for so-called "nested" hypervisors (think Blue Pill within a Blue Pill), and uses an architecture similar to that of the open-source Xen 3 virtual machine technology. It comes with "on the fly" loading and unloading features, as well as more features for avoiding detection, such as hibernating and temporarily uninstalling the hypervisor when Blue Pill detects that a tool is about to detect it.

Let me add: This utilizes Pacifica specification of AMD's newer processors which have virtualisation technology (VT) build-in. It just has been started on AMD processors but there are also implementations for Intel processors with similar techniques.

Having said all that I came to think of how could it still be possible to detect and what are the remarkable bits here. Let me also point out that I am by no means an expert on anti virus, Rootkits, hypervisors or any of that. I just know a some basic, though advanced, computer issues, how they basically work, about TCP/IP stuff and Linux OS basics. And I claim to have common sense :)

Ideas mentioned elsewhere to encounter the issue and comments on them:

Ok, now there is one point that is not technical at all: How do I detect something that can hide (let's presume so) from a running system if I don't see it and wouldn't get alerted by any detection software? Imagine working on your computer and thinking: "Am I infected? Let's check and boot to this detection LiveCD [see below]... checking... Good, not infected, so reboot to work system... keep on working... Oh, an now? Infected now?... LiveCD check... reboot to work, since still not infected... work a little... Hah, now is the time, I could now be infected... reboot....".

The rumours are that it would be easy to detect the malware hiding on active systems when the system is dormant, i.e. not booted, e.g from some LiveCD. That's one point I could believe to be true to some extant since I guess the malware has to have saved itself on system shut down to some place on the hard drive, BIOS (graphic card's one, too), or some kind of non-volatile memory and, more importantly, cannot defend, i.e. hide, itself actively. But as with any malware detection by signature the signature of such "saved state hiding malware" has to be known which might be hard since it's easy for malware to change it's "saved state form" and thereby it's signature. And also, is it handy and operably in real life to shut down, eg., servers "only" to detect potentially infected systems (again, assuming all the while it's not possible to detect while the system is active)?

If it's possible to only have one hypervisor (what I don't know right now) then wouldn't it be easy to just check if a hypervisor is present or can be enabled. If not because one is present already but not known about by the system -> suspicious. Matasano's virtualized rootkit detector most likely is about even more than that (from Hacker Smackdown, June 28th, 2007):

Ptacek, Lawson, and Ferrie contend that virtualization-based malware is actually easier to detect than a normal (non-virtualized) rootkit because basically by definition it leaves a trail, introducing changes in the system's CPU clock, for instance. And the malware would have to be bug-free to truly emulate a system, anyway, Ptacek argues. "The problem with virtualized rootkits is... They have to present the illusion they are talking to real hardware and that's not an easy task," he says. "In order to do that, you have to write a bug-free program whose job it is to emulate bugs. And we don't know how to write bug-free programs."

One very simply (that's why I liked it!) detection method described in a German forum was to simultaneously do an outside port scan and ask the system "from inside" for open ports. Most likely the malware will show an open port to the outside (it wants to receive data here) but will hide this port to the system running the malware.

Ideas I haven't read about so far or are not related directly but rather with malware in general but still fairly new:

• As a basic approach (operating) systems have to be transparent (best I know of open source) for experts to know what's going on inside and users to trust "their" system. This is no new argument I assume.
• Digital signature (public/private keys) handling in kernel for processes similar to what I believe Vista does but holistically and, again, transparent. The idea is similar to that Debian (and other distributions since) have been using with their repositories and dpkg/apt system for years now but now within the computer itself. SecureApt as it's called uses MD5 checksums (switch to SHA-1 when MD5 is broken) to uniquely and securely identify software packages retrieved from Internet repositories and to verify data (read byte stream) is unchanged on the way from the maintainer to the user's computer. On top of that SecureApt uses OpenPGP (with GPG) private keys to sign repositories release summaries and public keys to verify the signature, i.e. deciding whether a repo is trusted or not. Why not taking this one step further to the kernel itself and have a module in the kernel implementing the idea of SecureApt but for processes (instances of programs from those repositories)? Though, I guess with quantum computers approaching this prevention method most likely will not hold long anyway.
• Security systems (German) like AppArmor or even better SELinux should be used more widely to protect more systems better from so-called 0-day attacks and the like. And thereby limit distribution of malware. These two methods, of course, do nothing to increase detection on harmed systems. It only prevents from becoming infected.
• Don't by VT supported processors if you don't need to. This, as with all security issues, will not work on a wide range since it's more convenient to benefit from supposingly up to 95% performance enhancement for so-called paravirtualized guest systems (more precisely domUs). At least if you need to run unmodified OSs like MS Windows. If you can however modify the domUs, eg. Linux, you can have the same performance with eg. Xen. Let me point out that unlike virtualized guest operating system with paravirtualization the domU does know about it being virtualized and can, among others, access hardware directly.
• Another idea on how to become suspicious of possible infections includes a second system with net link to computers at risk. I'd call it a watch server or pass-through server. Maybe it could just be your firewall of choice. The idea is to watch the traffic from an to computers in your network just like a firewall does but watch for and learn some sort of network traffic signatures or patterns. This way you get a (statistical) profile of typical traffic regarding individual systems independent of applications running, user behaviour or or the like. Just plain network traffic. This, of course, has to be done while one is certain of no infections in the network. If one can guaranty this it could be possible after this learning phase to detect suspicious traffic.

Maybe everything said here is not new at all to others. But one thing I reckon will be true: After all it will always be a game of cat-and-mouse, since the bad guys will try to detect methods like those mentioned here to hide themselves and the good guys will always try to be smarter. The most interesting part I find about self hiding malwares is that malware is turning the tables now (well, not entirely): With conservative viruses it was evolving new techniques unknown to the anti-virus guys. Now it's (partly) malware becoming virus-detection-detectors.

And one other thing once again became clear to me: The need for researchers to "do bad things", i.e. to develop, test, execute, issue and whatever else necessary malware of whatever kind to be able to come up with antidote! Unfortunately there are movements on the way in Germany (German, heise, 06.07.2007 14:23) and as I understand in other parts of the would, too, to prohibit this.

Happy hacking ;)

Update 2007/10/11:

In slashdot there has been a note on VM-Based Rootkits Proved Easily Detectable pointing out an article from researchers from Stanford, CMU, VMware, and XenSource "Compatibility Is Not Transparency: VMM Detection Myths and Realities" (pdf). Unfortunatelly, untill now I haven't had the time to read it.

Resources:

• Computer Club Zwei web audio (30.07.2007 Episode 60)
• Computer Club Zwei forum thread (German, 26.09.2007 22:57)
• Hasch mich, ich bin ein Rootkit (German, on Heise News, 2007-07-04 11:28)
• The Invisible Things (blog of Joanna Rutkowska's company)
• Subverting Vista Kernel For Fun And Profit (About Joanna's talk at Black Hat Briefings on August 3rd 2006, original talk ppt)
• The Blue Pill Hype (Joanna's Blog again)
• Blue Pill Gets a Refill (2007-08-02)
• SecureApt at Debian's wiki (2007-09-08 17:57:23)
• Xen on Ubuntu's community wiki (2007-09-30 03:25:10)
• Rootkit Storm and Solutions with a list of Anti-Rootkit/removal tools (2007-01-21)
• Review: Six Rootkit Detectors Protect Your System, a fairly detailed rewiev (2007-01-16 09:51)
• Peacomm.C - cracking the nutshell, an analysis of Peacomm.C mechanisms by Frank Boldewin (2007-09-21)

Library, seems to be complete and to have good implementations of Common Algorithms, EllipticCurveCryptography, Certifications, OpenPGP, OpenSSL.

A part a little leak of performances in ECIES algorithm, seems to work great.

The big problem is that Hex Conversion functions have some problem, for example Hex.Decode() , fails when the string passed have an odd lenght.

To dayI've sent an email to the coders, hope in a fast reply, if i discover how to solve also other minor problems (actually no time to mention all) i'll post here the fixed piece of code ;)

See you to the next post :)

Cominciamo questa serie di articoli con una problematica molto attuale, la riservatezza dei nostri e-mail (Sul genere di "e-mail"). In una società dove in tutti i luoghi siamo spiati (nel bene e nel male, chi più chi meno), e soprattutto dopo aver letto, buttando un occhio all'attualità, delle intercettazioni illegali Telecom (e visto che i politici vogliono farsi una legge ad hoc per evitare di essere spiati, lasciando noi nell'oblio di sniffer e chi più ne ha più ne metta), visto che criptare le telefonate non è ancora economicamente possibile e visto che tutto ciò non è illegale, perchè non aggiungere delle barriere (funzionanti anche per i malintenzionati) alla sicurezza dei nostri e-mail?

Prima di tutto vi dico subito che per oggi tratteremo l'approccio con Mozilla Thunderbird in ambiente Windows. Se non l'avete e/o usate un altro programma di posta, vi consiglio caldamente di provarlo. (Ricordo di aggiornare alla versione 2.0.0.0 appena uscita).

Per avere un certo livello di sicurezza bisogna servirsi in alternativa di S/MIME o PGP o del suo omologo OpenSource GnuPG. Nel caso di S/MIME e PGP avremmo alcuni problemi legati sia al reperimento di certificati validi, sia di costi, perciò avviciniamoci alla soluzione OpenSource GnuPG: GnuPG è un semplice programma disponibile da riga di comando per generare le chiavi che vi serviranno a cifrare/decifrare i vostri messaggi di posta. Specifichiamo che questa soluzione, come d'altra parte tutte le altre, funziona solo se voi e i vostri destinatari usate questo metodo!

Allora cominciamo, i passaggi da effettuare sono questi:

1. Scaricare ed installare GnuPG
2. Scaricare ed installare Enigmail per Thunderbird
3. Configurare Enigmail
4. Generare la coppia di chiavi
5. Inviare la vostra chiave pubblica al server
6. Generare un certificato di revoca delle chiavi (nel caso perdeste le chiavi o la password)
7. Fare un back-up delle chiavi e del certificato.

Punto 1. Scaricate GnuPG dal suo sito prelevando la versione corrispondente al vostro sitema operativo (dalla versione 1.4.7 in poi vanno bene tutte) e installatelo in una cartella a voi comoda. Non preoccupatevi, non vi farò scrivere nulla da riga di comando!

Punto 2. Ora dobbiamo scaricare il plug-in per Thunderbird che ci aiuterà a gestire le funzionalità GnuPG: per fortuna questo plug-in c'è già e si chiama Enigmail. Scaricatelo dalla sezione Add-ons di Mozilla e installatelo tramite la procedura descritta (scaricate il file .xpi e da Thunderbird: Strumenti->Componenti Aggiuntivi->Estensioni->Installa).

Punto 3. Durante l'installazione dovrete localizzare GnuPG (anche se di solito lo trova da solo se lo avete installato nella cartella Programmi), quindi ricordatevi dove l'avete installato. Ora il vostro sistema è a un solo passo dal poter mandare e-mail sicuri. Apriamo Thunderbird e vediamo subito che nella barra dei menù è comparso il menù OpenPGP e un nuovo bottone (che ci interesserà solo dopo).

Cliccate su di esso e nel menù selezionate "Gestione delle chiavi". Vi apparirà una finestra con un elenco vuoto.

Punto 4. La procedura che segue andrebbe ripetuta per ogni vostro account di posta elettronica, ma potete anche utilizzare la cifratura con un solo indirizzo di posta. Selezionate l'ultima voce di menù, "Genera"->"Nuova coppia di chiavi". In "Account/ID Utente" selezionate l'account di posta col quale volete spedire e ricevere mail sicure, mettete la spunta al box "Usa la chiave generata per questa identità", poi scegliete una password (da riscrivere 2 volte per controllo) e NON dimenticatela!!! Potete anche inserire un commento, ma di solito non viene usato se non per casi di omonimia (Infatti il vostro indirizzo di posta verrà associato al vostro Nome e Cognome secondo le vostre impostazioni account). Lasciate il valore di default nel campo "Scadenza chiave" (mi sembra di ricordare 5 anni, o sbaglio?) e assicuratevi che in "Avanzate" sia selezionato l'algoritmo "DSA & El Gamal". Infine cliccate su Genera e verrà generata una coppia di chiavi.

Punto 5. Perchè tutti siano in grado di mandarvi messaggi privati cifrati hanno bisogno della vostra chiave pubblica, quindi è il momento di inviarla ad un server di chiavi pubbliche. Se siete ancora nel pannello "Gestione Chiavi OpenPGP" per farlo dovete solamente cliccare col tasto destro sulla vostra chiave appena generata e selezionare "Invia chiavi pubbliche al keyserver" e dal menù a tendina selezionate un keyserver a scelta (suggerisco pgp.mit.edu) e date OK.

Punto 6. Ora sarebbe bene creare un certificato di revoca nel caso in cui non foste più in grado di usare la vostra coppia di chiavi (i motivi sono molteplici, ma non starò qui ad elencarveli). Con la stessa procedura di prima andate in "GestioneChiavi OpenPGP" e col destro cliccate sulla vostra coppia di chiavi e selezionate "Crea & salva un certificato di revoca" selezionate dove volete salvarlo ed è fatta.

Punto 7. Per fare un back-up delle chiavi e dei cerificati dovete esportare le chiavi (la pubblica sia la privata) in un file e potete farlo sempre cliccando col destro su una chiave e selezionando "Esporta chiavi in un file, rispondendo sì alla domanda successiva e selezionando dove volete salvarlo. Fatto ciò potete raggiungere la cartella nella quale avete salvato il certificato di revoca al punto 6 e il file appena salvato con le vostre chiavi e spostarli su un dischetto o una chiave USB al riparo da occhi indiscreti.

Bene, ora che la procedura è finita, potete iniziare a mandare mail sicure a chi come voi usa questo sistema, quando manderete una mail selezionate una delle opzioni del menù mostrato qui sotto. Passate parola e magari in un futuro molto lontano questa sarà la prassi.

P.S.: Vi ricordo che con questa procedura ora potete cifrare il messaggio, firmare il messaggio e fare entrambe le cose, ma benchè la firma non altera il messaggio, e quindi questo è ancora visibile, la cifratura lo altera e lo rende incomprensibile a chi non usa OpenPGP, quindi, benchè possiate mandate messaggi firmati a chi non usa questo metodo, non mandate messaggi cifrati a chi non usa OpenPGP, altrimenti saranno per loro illeggibili. Anzi, mandateglieli e costringeteli ad usare OpenPGP... No, scherzo... o forse no?

Ciao alla prossima.