En esta entrada voy a dar una pequeña introduccion a openPGP y en las siguientes explicaré más a fondo su funcionamiento.

La librería

Las libreras que dan soporte a openPGP en java son de Cryptix OpenPGP que las pueden encontrar aquí http://www.cryptix.org/.

Esta librería a su vez necesita de Cryptix JCE que también se puede encontrar en la misma página.

Dependencias

Para que estas librerías funcionen se debe instalar la extensión Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy que se puede encontrar en la pagina de Sun http://java.sun.com/javase/downloads/index_jdk5.jsp en la sección Other Downloads.

Uso de la librería

En la descarga de la librería entre otras cosas vienen los fuentes de la misma, los binarios empaquetados en Jar y unos ejemplos para hacer uso de la misma.

Crear claves

Entre los ejemplos se encuentra uno para crear las claves públicas y privadas para poder encriptar y firmar.

cryptix\openpgp\examples\GenerateAndWriteKey.java

Encriptar

Tambien encontramos un ejemplo para encriptar de forma sencilla.

cryptix\openpgp\examples\Encrypt.java

 Des-encriptar

y encontramos un ejemplo para des-encriptar de forma sencilla.

cryptix\openpgp\examples\Decrypt.java

 Firmar

En las clases de ejemplo podemos encontrar una clase java que encriptar y firma un texto.

cryptix\openpgp\examples\EncryptAndSign.java

  Verificar Firma

Y como es logico podemos encontrar la clase para des-encriptar y verificar la firma de un texto.

cryptix\openpgp\examples\DecryptAndVerify.java

Ходил сегодня на очередное собрание местных “красноглазиков”. Кстати именно ходил – я решил, что от работы это будет не так уж и далеко, так что час между шестью и семью вечера я топал по центру от Чернышевской на 10-ю линию Василиевского острова. Прогулялся не плохо, так-как погода последние дни меня вполне радует, хоть и прохладно немножка.

Собрания эти хоть и проводятся каждый месяц, к сожалению не всегда кажутся настолько интересными, что бы их посещать. Иногда темы меня мало волнуют, иногда я вообще не знаю тематику намечающегося сбора…

В это раз вот был обещан рассказ про PGP – ИМХО вполне любопытной и полезной технологии. На примере абстрактного Василия Алибабаевича Пупкина было показано как можно завести себе ключик, как им подписывать другие ключики, как получать/отдавать на сервак хранения ключей, как аннулировать созданный ключь и нахрена собственно все эти манипуляции нужны. Так же продемонстрировали решение какой-то бубунтовой проблемы на счёт ключей, но к счастью я этим “дистрибутивом” не пользуюсь и проблем таких у меня нет.

Потом уже разговор понесло в холивары на тему аппаратных ключей и отмыва денег на их сертификации, мне же на данный вопрос класть и я решил уже к дому ехать.

ЗЫ: почему-то эта линуксовка показалась мне самой цивильной из виденных, с другой стороны она была и менее людной.

Thunderbird is a mail user agent developed by Mozilla. GnuPG is an encryption program (free software) that uses the standard OpenPGP. This standard is based on encryption using a private and public key. The private key is used to decrypt the data while the public key is used to encrypt the data.

The Thunderbird add-on Enigmail, provides an “back-end” interface to GnuPG so the user can use Thunderbird to encrypt/decrypt mail. After installing Enigmail, generate a keypair. This will create a public and private key for the current account. The public key is meant to be distributed so other people can send mail encrypted to you. The private key however, is important NOT to distribute. Since it is used to encrypt the messages sent to you with your public key. The public key is usually uploaded to a keyserver.

It’s possible to search for public keys on the keyservers and add public keys into a local list and configure Thunderbird to encrypt all messages by default (supposing the public key to the person in question is added into your key list). Both Thunderbird, GnuPG and Enigmail, are very useful indeed : )

For more information about GnuPG and Enigmail:
http://www.gnupg.org/
http://enigmail.mozdev.org/home/index.php

Aunque la criptografía es un tema matemáticamente complejo, las herramientas actuales permiten utilizarla sin necesidad de ser un friki de la Nasa.

Aquí explicare en 4 pasos como montarse un correo encriptado con GnuPG, que es una herramienta de cifrado basada en software libre, que viene a remplazar al clásico PGP de software propietario. Como aplicación para gestionar el correo usaremos Thunderbird de la familia Mozilla y para hacer la interacción entre el motor de encriptación GnuPG y Thunderbird usaremos Enigmail.

1. Instalación del motor de encriptación
Usaremos para esto el GnuPG 1.4.7 para Microsoft Windows se debe descargar e instalar tal cual viene por defecto.

2. Instalación del programa de Correo
Para recibir nuestro correo usaremos Thunderbird que es la versión libertaria para correos de la familia Mozilla, el cual se puede descargar aquí Thunderbird 2.0.0.6. Usaremos una versión en ingles, ya que los softwares se desarrollan en esta lengua, y para ahorrarnos problemas de compatibilidad entre GnuPG, Thunderbird y Enigma, preferimos dejar todo en ingles.

Una vez instalado cargaremos la cuenta de correo que queremos usar en la aplicación, como si fuera cualquier correo común.

3. Instalación del Accesorio de Cifrado para Thunderbird
Para esto usaremos Enigmail v0.95.3 se debe descargar este archivo al escritorio e instalarlo desde Thunderbird (Tools > Add-ons > Install) este pedirá reiniciar Thundebird

Ya tenemos todos los sistemas instalados, ahora solo debemos configurar nuestra cuenta para poder usar nuestro correo cifrado.

4. Configuración de la Cuenta de Correo
Desde el cliente de correo Thunderbird, tendremos configurada almenos una cuenta de correo. En el menu (OpenGPG > Key Management) podemos ver un listado de todas las claves que tengamos importadas en el sistema.

En esta ventana, el menu (Generate > new key pair) nos proporciona la ventana para poder generar un nuevo par de claves.

Solo nos queda rellenar la passphrase y opcionalmente el comentario para identificar la cuenta a la que se refiere. En (advanced) nos preguntará el tamaño de encriptación de la llave, mientras mas alta es mas segura, pero también, mas lento, podemos elegir 1024, 2048 o 4096 para mas seguridad, y en algoritmo de encriptación usaremos DSA y El Gamal.

Ahora ya tenemos un par de claves generadas, solo queda darles un uso. Pero para esto el resto del mundo ha de conocer nuestra clave pública para poder cifrarnos mensajes. Esto podemos hacerlo de dos formas, o bien subiéndolas a un servidor de claves, o enviarlas por correo electrónico a nuestros amigos.

Para subirlas al servidor de claves, desde el (Key Management) antes citado, podemos hacerlo perfectamente.

Seleccionamos nuestra clave, botón derecho, (Upload to keyserver). Ahí seleccionamos el servidor al que queremos que vayan (recomiendo el subkeys.pgp.net o el del mit ya que todos los sistemas lo consultan), aceptamos y listo. Ya te pueden buscar por la dirección de correo o el nombre. No hay que preocuparse, ya que los servidores de claves PGP se comunican entre ellos dando a conocer nuestra clave publica al resto de servidores.

La otra opción de enviarlas por correo es mas sencilla. Con Thunderbird creamos un nuevo correo, ponemos la dirección del destinatario, el asunto y en el cuerpo del mensaje lo que queramos. Finalmente adjuntamos nuestra clave pública desde el menú (OpenPGP > Attach My public key). Es recomendable firmar el mensaje para certificar que el mensaje ha llegado sin modificaciones desde que se emitió hasta que le llego al destinatario y así saber que la clave que ha llegado es la autentica y no una falsificación

Moved to http://www.amiryan.org/2009/02/03/problem-with-apxs-under-fedora-7-x86_64/

In der neusten Datenschleuder (#93) welche seit dieser Woche in die Briefkästen ihrer Abonnenten befördet wird ist ein sehr interessanter Artikel von Hannes Mehnert mit dem Titel: “Secure Instant Messaging – am Beispiel XMPP” .

In diesem Artikel wird sehr schön das XMPP-Protokoll an sich erläutert und dann ausführlich auf verschiedene Sicherheitsaspekte eingegangen. Sowohl die Client – Server, wie auch die Server – Server Verbindung wird dabei analysiert. Dann folgt eine Erläuterung der beiden verbreitesten Verschlüsselungsarten beim IM: OpenPGP und OTR, wie sie funktionieren und was ihre Vor-/Nachteile sind. Danach folgt noch eine kurze Beschreibung über die Funktionsweise und Probleme beim anonymen chatten über XMPP mit Hilfe von Tor.

Bei der Analyse wird auch jeweils auf die Implementationen innerhalb der Clienten: Adium, Gajim, Pidgin und Psi eingegangen, als auch auf die unterschiedlichen Serverimplemenationen ejabberd, jabberd-2 und jabberdI.

Kurze Zusammenfassung des Artikels: Keine momentane Serverimplementation besitzt einen verlässlichen Zufallszahlengenerator welcher Vorraussetzung für eine sichere Authentifizierung mit SASL (DIGEST-MD5) oder Digest-Authentifizierung ist. ejabberd hat jedoch die Nase etwas vorne, da sein Zufallszahlengenerator auch die Millisekunden des Zeitpunktes vom Server-Startup miteinbezieht. Bei den Client-Implementationen sieht es sicherheitstechnisch noch etwas schlechter aus, als bei den Server-Implementationen. So ist zum Beispiel laut Artikel keine stable-Version eines der oben genannten Clienten in der Lage ein Zertifikat für die nächste Verbindung zu speichern und somit die Integrität des Servers zu überprüfen. Psi, Audium und Gajim scheinen dem jedoch in den neusten Versionen in Subversion abgeholfen zu haben, weswegen es sich anbietet die Development-Versionen eines dieser Clienten zu nutzen.

Zu den Verschlüsselungsmethoden: OpenPGP hat den Nachteil, dass sollte jemals der private Schlüssel in die Hände eines Unbefugten gelangen, dieser jede jemals mit ihm verschlüsselte Nachricht entschlüsseln kann. Bei OTR besteht diese Gefahr nicht da bei jeder Verbindung ein neuer Schlüssel ausgehandelt wird. Dafür hat OTR Probleme mit Latenzen, also wenn zum Beispiel eine Nachricht erst ankommt, nachdem bereits ein neuer Schlüssel ausgehandelt wurde kann sie nichtmehr entschlüsselt werden. Dies wird momentan von den Clienten nur bedingt durch einen Nachrichten- und OTR-Schlüsselcache verhindert , welcher aber wiederum die Sicherheit von OTR gefährdet. Offline-Nachrichten sind mit einer sicheren OTR-Implementation auch nicht möglich.

Fazit: Das offene XMPP-Protokoll an sich ist sehr geeignet für eine sichere Kommunikation, doch die momentanen Implementationen lassen noch etwas zu wünschen übrig, auch wenn Fortschritte eindeutig zu verzeichnen sind.

Freundlicherweise stellt Hannes diesen Artikel nicht nur den Lesern der Datenschleuder zur Verfügung (denn die PDF-Variante dieser wird wahrscheinlich erst in ein paar Monaten erscheinen) sondern bietet den vollständigen Artikel auch als Download an: https://berlin.ccc.de/~hannes/secure-instant-messaging.pdf .

La criptografía (del griego kryptos, “ocultar”, y grafos, “escribir”, literalmente “escritura oculta”) es el arte o ciencia de cifrar y descifrar información utilizando técnicas matemáticas que hagan posible el intercambio de mensajes de manera que sólo puedan ser leídos por las personas a quienes van dirigidos.

Con más precisión, cuando se habla de esta área de conocimiento como ciencia se debería hablar de criptología, que engloba tanto las técnicas de cifrado, la criptografía propiamente dicha, como sus técnicas complementarias: el criptoanálisis, que estudia los métodos que se utilizan para romper textos cifrados con objeto de recuperar la información original en ausencia de la clave.
La finalidad de la criptografía es, en primer lugar, garantizar el secreto en la comunicación entre dos entidades (personas, organizaciones, etc.) y, en segundo lugar, asegurar que la información que se envía es auténtica en un doble sentido: que el remitente sea realmente quien dice ser y que el contenido del mensaje enviado, habitualmente denominado criptograma, no haya sido modificado en su tránsito.

Habiendo explicado brevemente lo que es la criptografía, podemos hablar de una de las herramientas que nos permite utilizar esta ciencia para asegurar el destino de nuestra información.

¿Que es el PGP?

Quizás algunos de ustedes no sepan lo que significa PGP (Pretty Good Privacy) o Privacidad Bastante Buena, este es un programa desarrollado por Phil Zimmermann y cuya finalidad es proteger la información distribuida a través de Internet mediante el uso de criptografía de clave pública, así como facilitar la autenticación de documentos gracias a firmas digitales. PGP originalmente fue diseñado y desarrollado por Phil Zimmermann en 1991.

La IETF se ha basado en el diseño de PGP para crear el estándar de Internet OpenPGP. Las últimas versiones de PGP son conformes o compatibles en mayor o menor medida con ese estándar. La compatibilidad entre versiones de PGP y la historia del esfuerzo por estandarizar OpenPGP.

Seguridad PGP

Utilizado correctamente, PGP puede proporcionar un gran nivel de seguridad. Es más, observadores informados creen que ni siquiera las agencias del gobierno estadounidense como la NSA son capaces de descifrar directamente mensajes generados adecuadamente con PGP.

PGP es más fácil de utilizar que muchos otros criptosistemas, pero como ocurre siempre en el campo de la criptografía, su implementación y su utilización influyen muchísimo en la seguridad lograda. Existe la posibilidad de que haya errores en la implementación, y si se utiliza descuidadamente es posible desproteger fácilmente un archivo de texto protegido. Cualquier criptosistema puede ser inseguro, independientemente de lo bueno que sea su diseño.

A diferencia de protocolos de seguridad como SSL, que sólo protege los datos en tránsito (es decir, mientras se transmiten a través de la red), PGP también puede utilizarse para proteger datos almacenados en discos, copias de seguridad, etcétera.

El inconveniente es aunque incluso tenemos en nuestro poder el código fuente, este es un software propietario, aunque esto no es un problema si tenemos el dinero para pagar el costo de una licencia y como aseguran muchos expertos el estándar PGP es virtualmente indescifrable. Así que ellos cobran por un producto que aseguran funciona.

Avrundade kvällen med att installera och prova GnuPG i Thunderbird och via gmail i Firefox. Tack till projO för guiden och till Daniel som stod till hands att testa mot.

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 – 6616326F – ä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.3 (MingW32)

mQGiBEh1xj8RBACOKRK67ozKZE36S9IEDirwK6I50NX1NmWVnLTZdExEl1apTUg9
ZnFFMW0RV4O6K63in/Bvv2zRSBg1eMbI4EGmdJHH3UfPAiTKfFZgMS10zRDSvzM6
ncXKf+rtMUBvElR8ZEWX0BsaudGQgSHDOX9hM7NGxsoZRsvdcYm0Ga83fwCgvbLM
ae+GeUNmh9Dc/F6FyLoIK58D/27ITPNcFrvqzFKuSfqFfQrsB4kkrblJBPUGwrAf
aQvaZXXihGGIyYuh3mIPK9wWxea+sQZI/SYAA2+5MRVE++m9cdRmFIkjDDZGfdS1
IswtyKxIPi8ljJm5SPBFetSRxQCUJdZrj20Nae4TfXc2WIloTlwcUPKNAF+pdOUL
p4iUA/9jBx0CN9Lt7TTtj8EthuqiZ9yi+5ouR45KjryP/QZpAG2SOcHvNg1Hlrwy
ryXZvxl8EnbPbRGVOJAO373E49UILaGAWygvnfydMgRS7FI8KKujEbkymW2tL1Pt
x5CtTLrZjY8gni1eGbSvPtEmThC3cvtsYt/TZO+5i0gZpoLj6bQpSm9oYW4gRGFs
ZW5pdXMgPGpvaGFuLmRhbGVuaXVzQGdtYWlsLmNvbT6IZgQTEQIAJgUCSHXGPwIb
IwUJCWYBgAYLCQgHAwIEFQIIAwQWAgMBAh4BAheAAAoJEEq+PT1mFjJvObgAn1Ag
iukpoboTbTbryEiFgPj8iqV4AKCHnxwz3EBEnzpWwO4cXVmLzU6zZLkCDQRIdcZH
EAgArCnA8YiFLjWRscXZBbqxEK2zUeLUHBjcjk50j2vxR3V2H/ZSeM+FTnMH+rU9
X+RtMPgTAC903ToGJ/oGspXtmF+k7G/LWI9deWT/Y2/BTY06DxdQ63jaPQ87xWrR
JKm1Edc7u5jEja0ITZE7tgFHWeCakripeMJfaSxTmnXnjVETeyNvX870mD1QsQsJ
1+va3QneppKSPiTL35rqNkpil5JjREr+zCUZVG2kvU4dZDlR1SpzjadcZe5VAzJo
BsXNXYzsFvLp6SVSC75U72XSMLCXunrit4ic1X/DPUhQFet8pRynMT4QjNf8CWjz
gf4WP+pbFHqT0YYTjqXHsc0B2wADBQf/YcVUrWpyA+Fnf2tnUmlGutzTpM8ESDW4
TsO7t1qkTwgbKhi/qhDB5yDlW02Qilmap2mQQlI0e3vdt2BoNxkcAhC9s1BImALN
OqWA497U/HXhPdLaV0zPcGTGHX5OZBCErWN5+OKbHFP8y00/ULSge/bvAD+XHZbW
/dfYO7sEYdXurt0G2gsT6TUpM87Ijem3pSPc5BMgYjZflWNHenJJkYkjhplG4Gg4
lY1c92SLKDWlTR6oK5awkMF6RBnnVdIZasl3/puSlPhE7NEJL+aSOFMW/A518huK
OyBZKuiUFYe5hx1KI4NwMaczsWFfMPDTFBpY/ijT4jy0Frs0LUKse4hPBBgRAgAP
BQJIdcZHAhsMBQkJZgGAAAoJEEq+PT1mFjJvDIMAnRdHM62F658lsMpg5LByeefg
XMtcAKCgIAfhV8U+Nw2n96CD+V8MZPDvDw==
=yvBA
—–END PGP PUBLIC KEY BLOCK—–

Uppdatering. På grund av bristfällig planering i samband med ominstallation så gick min gamla nyckel om intet. Posten är uppdaterad med aktuell nyckel.

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

Im Zuge der Vorratsdatenspeicherung und der geplanten Online-Durchsuchungen wäre es vielleicht doch sinnvoller, einmal über die Verschlüsselung seiner Daten nachzudenken, zum einen phyisch, also direkt auf der Festplatte, als auch beim Versenden über das Internet. Beim Versenden über das Internet bietet sich für den Mozilla Thunderbird – Mailclient die praktische Erweiterung “Enigmail” an. Einmal in Thunderbird installiert, lassen sich schnell Schlüssel für GnuPG anlegen, mittels denen dann die eMails vor dem Versand verschlüsselt werden.

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.

Calling Hushmail a scam (which seems lower in the continuum than
Snake Oil) is pretty strong. I have been (and am) a Hushmail user
for many years and have been impressed by how they go about their
business. They are pretty explicit in explaining how things work,
opening the code up for review, using OpenPGP, non US servers and
incorporation, etc.

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/Ioyw6h4fRTdts2rXzvypA08i4×4ZY17uNW0IOfxYNnLUwGHrYCe6DW/

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

In the last couple of days I have been reading and hearing about Rootkits and the panic that comes with it. Mainly on German forums and sites, although also e.g. on Joanna Rutkowska’s blog (author of the “famous” Bluepill hijacker technique). And it kept me thinking. But first let me summerize what I understand the fuzz is all about.

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)

GnuPG is the GNU project’s complete and free implementation of the OpenPGP standard

Da oggi voglio cominciare una serie di articoli, non necessariamente successivi l’uno all’altro o temporalmente vicini, che trattano di tematiche di sicurezza, in modo semplice ed efficace, senza spiegare tutto ciò che ci sta dietro per ovvie ragioni di spazio/tempo, ma spiegando come un utente di PC non molto esperto potrebbe beneficiarne.

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.