Felipe Alfaro Solana

In case you are worried about Bonjour sending advertisements onto the local network because it compromises your privacy or because you are worried about security, know that you can disable them. It is described in http://support.apple.com/kb/HT3789:

$ cd /System/Library/LaunchDaemons
$ sudo vi com.apple.mDNSResponder.plist

and replace:

        <array>
                <string>/usr/sbin/mDNSResponder</string>
                <string>-launchd</string>
        </array>

with

        <array>
                <string>/usr/sbin/mDNSResponder</string>
                <string>-launchd</string>
                <string>-NoMulticastAdvertisements</string>
        </array>

Does Google Chrome plug-in and extensions security model allow for a plug-in or a extension to hijack certain operations in the browser, like spoofing DNS name resolution?

What is the likelihood for an extension, like LastPass for Chrome, to hijack the browser’s DNS name resolution process in such a way that, when the user is redirected to a site like PayPal, in fact he or she is redirected to something that looks like PayPal but is not? If an extension or plug-in can hijack the browser’s DNS name resolution process, the browser’s address bar might read like http://www.paypal.com/ but the actual browser would have, in fact, established HTTP/TCP connection against another Web site that looks like PayPal’s but using a different, non-legitimate IP address.

I was reading the comments for Schneier’s is antivirus dead? article. As usual, Bruce Schneier is sharp and gets the whole picture.

One of the comments from that article said to stop using Windows. Not using Windows is, unfortunately, the wrong solution. Other platforms like Mac OS X have serious security bugs. Linux had have also security bugs, and so does Solaris. Even OpenBSD might have security bugs that have yet to be discovered. The more people start using Mac OS X, Linux, Solaris or any other modern operating system, the more these vulnerabilities will be exploited. While other operating systems might (or might not) be more secure than Windows doesn’t mean they are not vulnerable to exploits. And the more critical mass these operating systems get the more interested hackers will be in actively exploiting even the smallest security bug. As long as an OS has a exploitable bug there is potential for compromise. And even if the OS is completely secure we still have untrained users

Another comment mentioned that code-signing is the solution to stop malware, but I have to strongly disagree. A hacker can potentially get its code signed and pushed to you. That code is then run and the system infected by a trojan or malware. It is true that getting malicious code signed is not trivial, but I’m sure a good hacker can deceive some well-known signing authorities. And by the time you get infected by signed code it will be difficult to know what exactly infected your system. It will be difficult to prove whether it was that suspicious, but digitally-signed code that you recently downloaded from a Website or something else you downloaded months ago. At that point, if the system is compromised, evidence might have been destroyed.

While reading a post on how current anti-virus solutions are starting to become complete inefficient and even reporting false positives, a few thoughts came to my mind.

The first one is that I’ve been running with no anti-virus on my computers for more than 8 years now. The use of low-risk platforms, like UNIX-based systems, and systems with a low market share like Mac OS X, combined with common sense, education and caution has kept me safe from viruses, trojans and other malware for this long.

The second thought is that current anti-virus software is outdated, and does not meet expectations, nor does it meet currently system designs. I think anti-virus analysis should be done in a distributed fashion. For corporations, samples can be distributed and analyzed across workstations and those that are suspect of being evil can be sent to the anti-virus manufacturer for further analysis. For end-users and consumers, samples can be distributed and analyzed by clusters of machines, provided typically by the anti-virus manufacturer, that are properly secured and trusted, all in a peer-to-peer fashion.

The third idea is that no matter how analysis is done, the long-term solution consists of fixing current applications, operating systems and hardware architectures to make exploits and malware more and more difficult, and also to educate end-users. In my opinion, education is the most efficient way of preventing this attacks because it’s cheap and usually has impact on the short- and long-term. Common sense and education can deter most attacks and security problems.

What are your thoughts on this?

It is probably not very well-known for many, and probably ignored by most, but it seems that Mac OS X and specifically Safari leaves much to be desired when talking about security.

During the Pwn2Own contest, Safari was the first browser to fall, in the order of seconds, when put under attack by Charlie Miller. This has been reported in several places, like Pwn2Own 2009: Safari/MacBook falls in seconds, or Miller: Safari on Mac First to Fall During PWN2OWN Contest, or Miller Cracks Safari Within Seconds, Wins PWN2OWN Contest. For the second year in a row, Safari/MacBook has been the browser to fall under attack the first.

So, if you are a user of Mac OS X, be very careful when using Safari. These attacks so far require you to click on links specifically crafted to cause harm to your computer, which might allow the attacker to gain total control of your machine. Hence, the importance of never running with an account that has administrative privileges.

Leyendo un artículo de Kriptópolis, me encuentro con una referencia a Peter Tippett en la que éste hace un símil entre la seguridad en la industria automovilística y la industria de la seguridad informática. Aunque puedo coincidir con este señor, creo que no es una comparación del todo justa. En primer lugar, un coche es un componente del mundo real que realiza unas funciones concretas (aunque pueda utilizarse para otros fines no contemplados, como descubrir el amor en la adolescencia o rodar colina abajo). Normalmente el coche ofrece menos complejidad que un sistema software, a pesar de que cada día tengan más electrónica, ya que está diseñado para un fin muy específico: gastar combustible, y por ello pagar más impuestos, u obligarme a pagar el impuesto de matriculación y circulación (más impuestos).

Los sistemas informáticos, por el contrario, suelen ser bastante más complejos y también más genéricos o configurables (tomo por ejemplo KDE 4.0.1 que ofrece una barbaridad de opciones de configuración y adaptación que nadie sabe cómo usar realmente), lo que aumenta la complejidad exponencialmente. El problema es que no es humanamente posible diseñar casos de prueba para todas las posibles combinaciones (no sólo del sistema como un ente autónomo, sino del sistema en cooperación con otros, como KDE interaccionando con D-BUS que a su vez interacciona con UDEV que a su vez interacciona con el núcleo). A veces las interfaces no están suficientemente blindadas y simplificadas porque se busca flexibilidad y la capacidad de adaptar el sistema a demandas futuras sin necesidad de re-escribir todo el sistema desde cero (véase como ejemplo SAP R/3, que requiere habitualmente de 14 a 30 meses de configuración para adaptarse a cualquier tipo de empresa, desde la que hace blanqueo de dinero a la que vende bacalao o queso). Hacer estas interfaces tan flexibles hace que puedan ser utilizadas de forma errónea (y que el cliente de la interfaz o el mismo servicio funcionen erráticamente) y que simplemente contengan fallos porque no es factible probar todas las posibles interacciones (llamar al método foo() y después al método bar() para después llamar al método yada(), … combinación que raramente se utiliza), ya sea por costes monetarios o de tiempo (algunos proyectos tienen que ser entregados en algún momento, no como Windows Vista que se puede demorar ad-infinitum sin que a nadie le importe). Como dicen muchos, la complejidad es el mayor enemigo de la seguridad. Por consiguiente, es imperativo que nosotros (y cuando digo nosotros realmente quiero decir vosotros) pongamos algo de cordura a la complejidad que nos rodea y nos deshagamos de esa nevera que tenemos en la cocina con pantalla LCD de 20″ incorporada que hace cubitos de hielo y la lista de la compra y que viene con conexión a Internet y que la reemplacemos por una de esas neveras que usaban nuestras abuelas que sólo tenían una puerta y ni siquiera un botón para encenderlas o apagarlas (menos aún un botón para resetear, como el que traen las que vienen con Windows Mobile).

Además de todo lo expuesto anteriormente, creo reducir la seguridad de un “PC” (sobre todo si es un PC son un sistema operativo de baja calidad, con demasiadas funcionalidades y poco personalizable) a su punto de conexión en la red es un craso error. Cuando hablo de “punto de conexión a la red” me refiero a depender de cómo me conecto a Internet: desde mi casa con mi propio cortafuegos suministrado por Telefónica con las contraseñas por defecto habilitadas, o en un cibercafé a través de una red inalámbrica abierta que comparto con aquel señor de la otra esquina y aspecto inquietante. En cualquiera de los dos casos, el nivel de seguridad obtenido es diferente (sobre todo si el señor de la esquina tiene un aspecto realmente inquietante). Si el “PC” es un PC de escritorio (preferiblemente de más de 10 kilos y sin asa para poder pasearlo libremente), es probable que el punto de conexión a la red no cambie y, por ende, el nivel de seguridad permanezca relativamente estable a lo largo del tiempo (puede que tu “PC” con Windows adquiera algunos “inquilinos” traviesos con el paso del tiempo, pero su seguridad no se degradará mucho ya que anteriormente era, de por sí, realmente inseguro). Sin embargo, en dispositivos portátiles o móviles supone un problema mayor. Por ello, es importante asegurar el disposito en sí mismo, eliminando servicios innecesarios, usando un cortafuegos, usando herramientas como NoScript y navegadores seguros (aunque algo inestables como el Firefox), usando el sentido común (el menor común de los sentidos), utilizando gestores adecuados de contraseñas y disponer de múltiples de ellas (usar el PIN de la tarjeta de crédito como contraseña para registrarme en aquel sitio en el que me juraban regalarme un viaje al Túnez si me daba de alta), no usar Windows ni Mac OS X (a cual peor) ni tampoco Linux (mejor un sistema operativo raro, como QNX, MS-DOS o quizá FreeBSD), limitar las horas de navegación a la semana a menos de 300, y no consultar sitios potencialmente peligrosos (como Windows Live! o la página de El Mundo), pueden ayudar a incrementar el nivel de seguridad del usuario sin necesidad de depender en el punto de conexión a la red.

Con esto no quiero decir que la seguridad de la red no sea importante. Todo lo contrario. Pero dado que cada día es más habitual utilizar redes inalámbricas y que dejamos otros usuarios las usen y compartan con nosotros (lo digo como buen FONero que soy), como amigos, novias o vecinos con ADSL de 1Mbps de Terra. Por ello, la frontera entre lo que es “mi” red y el “resto” es cada día más borrosa y es necesario aplicar el concepto de seguridad por niveles y asegurar todos y cada uno de los componentes. Y eso incluye esta antigua impresora HP LaserJet con el adaptador de Ethernet que alguien compró hace 12 años y que un día se quedó sin tóner y papel porque un hacker se coló en la red y mandó a imprimir el manual de usuario de AutoCAD 9.

En definitiva: os recomiendo que veáis más la televisión y la Fórmula 1 y que dejéis de escuchar la radio o leer periódicos normales o navegar tanto por Internet porque es peligroso y, en general, sólo se encuentran piratas, friks o gente con ideas descabelladas y estúpidas o con ganas de robarnos el dinero o extorsionarnos (desde Rusia, con Amor).

0. Introduction

Enabling Kerberos/GSSAPI support in Leopard’s Remote Login (SSH) service is straightforward. As Leopard’s Remote Login is built using OpenSSH, most of what is described here applies perfectly to other flavors of UNIX.

Kerberos/GSSAPI authentication allows for Single Sign-On capabilities in OpenSSH in such a way that it makes very convenient to work with or manage multiple machines while only having to authenticate to the network every certain amount (Kerberos uses a form of cached credentials that expire within hours, typically). In this document I describe how to enable support for Kerberos/GSSAPI authentication to Leopard’s implementation of OpenSSH. Leopard includes many of the tools from the MIT’s implementation of Kerberos, so this makes the whole process even easier.

The process consists on:

1. Creating the Kerberos principal
2. Creating /etc/krb5.conf
3. Adding the Kerberos principal to the keytab file
4. Reconfiguring OpenSSH to support Kerberos authentication
5. Restarting OpenSSH
6. Enabling Kerberos authentication on OpenSSH clients
7. Testing

1. Creating the Kerberos principal

When a Kerberized SSH client tries to authenticate to a Kerberized OpenSSH service, the client will request a Kerberos service ticket for that specific OpenSSH service. The Kerberos service ticket contains, among other things, a shared secret (for example, a 3DES private key) that has to be distributed to both the client and the server, called K<>client,server. The KDC will generate such shared secret and will encrypt it twice. Once, with a shared secret between the KDC and the client principal, called K_KDC,client, and another one with a shared secret between the KDC and the server principal, K_KDC,server.

In this step, we will create the Kerberos principal that represents the OpenSSH server and consequently its shared secret, K_KDC,server. Later on, we will upload this shared secret to the OpenSSH server and install it into the Keytab file, so that the OpenSSH server can access it and use it to decrypt the user’s service ticket in order to retrieve the shared secret, K_{client,server}.

$ kadmin
Authenticating as principal alice/admin@LAN with password.
Password for alice/admin@LAN:
kadmin:  addprinc -randkey host/ssh.lan
WARNING: no policy specified for host/ssh.lan@LAN; defaulting to no policy
Principal "host/ssh.lan@LAN" created.

NOTE: If you are logged in as root into the KDC, you can use kadmin.local instead of kadmin if you prefer, as the former doesn’t require any authentication (being able to run it as root is enough to prove yourself authorized).

The Kerberos principal associated with the OpenSSH has been created, the shared secrets generated, stored and protected by the stash key. We can check the status of the principal using the following command:

kadmin:  getprinc host/ssh.lan
Principal: host/ssh.lan@LAN
Expiration date: [never]
Last password change: Thu Dec 06 19:42:50 CET 2007
Password expiration date: [none]
Maximum ticket life: 0 days 10:00:00
Maximum renewable life: 7 days 00:00:00
Last modified: Thu Dec 06 19:42:50 CET 2007 (root/admin@LAN)
Last successful authentication: [never]
Last failed authentication: [never]
Failed password attempts: 0
Number of keys: 2
Key: vno 5, Triple DES cbc mode with HMAC/sha1, no salt
Key: vno 5, DES cbc mode with CRC-32, no salt
Attributes:
Policy: [none]
kadmin:  exit

Now that the principal has been created, we can move onto the next step.

2. Creating /etc/krb5.conf

One of the requirements for Kerberizing OpenSSH server is configuring the Kerberos libraries via /etc/krb5.conf. These libraries are used by the OpenSSH server, kpasswd, the OpenSSH client and tools like kadmin or kinit.

This configuration file will also allow us to connect to the Kerberos administration server remotely by using kadmin, in order to download the OpenSSH shared secret. In my case, /etc/krb5.conf looks like this:

[libdefaults]
        default_realm = LAN
        dns_fallback = "no"
        default_tgs_enctypes = des-cbc-crc
        default_tkt_enctypes = des-cbc-crc

[realms]
        LAN = {
                kdc = kdc.lan:88
                admin_server = kdc.lan:749
        }

[domain_realm]
        .lan = LAN

[login]
        krb4_convert = true
        krb4_get_tickets = false

3. Adding the Kerberos principal to the keytab file

root@ssh.lan:# kadmin
Authenticating as principal root/admin@LAN with password.
Password for root/admin@LAN:
kadmin:  ktadd -k /etc/krb5.keytab host/ssh.lan@LAN
Entry for principal host/ssh.lan@LAN with kvno 7,
 encryption type Triple DES cbc mode with HMAC/sha1 added to
 keytab WRFILE:/etc/krb5.keytab.
Entry for principal host/ssh.lan@LAN with kvno 7,
 encryption type DES cbc mode with CRC-32 added to
 keytab WRFILE:/etc/krb5.keytab.

This will add the OpenSSH shared secret to the Kerberos /etc/krb5.keytab file. We need to add the shared secrets to this file properly, as Leopard has a built-in KDC service and machine-specific shared secrets in this file that are used, among others, by the Screen Sharing service, the AFP service and the SAMBA service.

To check that OpenSSH shared secret was added to the keytab file, we use ktutil to read and display the contents of the Keytab file:

root@ssh.lan:# ktutil
ktutil:  rkt /etc/krb5.keytab
ktutil:  list
slot KVNO Principal
---- ---- ---------------------------------------------------------------------
   1    3 afpserver/LKDC:SHA1.E803840ADEAA3E91BF895E969F56FEDFF321BDD5@LKDC...
   2    3 afpserver/LKDC:SHA1.E803840ADEAA3E91BF895E969F56FEDFF321BDD5@LKDC...
   3    3 afpserver/LKDC:SHA1.E803840ADEAA3E91BF895E969F56FEDFF321BDD5@LKDC...
   4    3 cifs/LKDC:SHA1.E803840ADEAA3E91BF895E969F56FEDFF321BDD5@LKDC...
   5    3 cifs/LKDC:SHA1.E803840ADEAA3E91BF895E969F56FEDFF321BDD5@LKDC...
   6    3 cifs/LKDC:SHA1.E803840ADEAA3E91BF895E969F56FEDFF321BDD5@LKDC...
   7    3 vnc/LKDC:SHA1.E803840ADEAA3E91BF895E969F56FEDFF321BDD5@LKDC...
   8    3 vnc/LKDC:SHA1.E803840ADEAA3E91BF895E969F56FEDFF321BDD5@LKDC...
   9    3 vnc/LKDC:SHA1.E803840ADEAA3E91BF895E969F56FEDFF321BDD5@LKDC...
  10    7                      host/ssh.lan@LAN
  11    7                      host/ssh.lan@LAN

Once installed in the keytab file, OpenSSH will be able to access the shared secret, K_KDC,server used to decrypt Kerberos service tickets shown by clients.

It is also necessary to change OpenSSH’s server configuration file, /etc/sshd_config to explicitly enable Kerberos/GSSAPI authentication. To achieve this, modify /etc/sshd_config file and add the following lines (by default they are either uncommented or disabled):

# GSSAPI options
GSSAPIAuthentication yes
GSSAPICleanupCredentials yes

5. Restarting OpenSSH

To last step on the server side requires that we restart the OpenSSH service so the previous changes are taken into effect:

root@ssh.lan:# launchctl
aunchd% stop com.openssh.sshd
launchd% start com.openssh.sshd

6. Enabling Kerberos authentication on OpenSSH clients

Some OpenSSH clients have Kerberos authentication disabled by default. The easiest way to enable Kerberos/GSSAPI authentication in clients is by adding the following directives to $HOME/.ssh/config:

Host *
        Protocol 2
        GSSAPIAuthentication yes
        GSSAPIKeyExchange yes
        GSSAPIDelegateCredentials no
        GSSAPITrustDns no

This will enable Kerberos/GSSAPI authentication on the client side. The fact that Kerberos/GSSAPI authentication succeeds depends on several factors, like the user having a valid Kerberos TGT, the remote server having Kerberos/GSSAPI authentication enabled, and that the clocks on both the client and server machines are synced (most implementations refuse Kerberos/GSSAPI authentication if the clocks differ more than 5 minutes).

7. Testing

First, we need to get a TGT from the Kerberos KDC:

$ kinit
Please enter the password for falfaro@LAN:

To check that it worked, we list the tickets available to us, and make sure we see a ticket valid for service krbtgt/*:

$ klist
Kerberos 5 ticket cache: 'API:Initial default ccache'
Default principal: falfaro@LAN

Valid Starting     Expires            Service Principal
12/06/07 18:06:26  12/07/07 04:06:26  krbtgt/LAN@LAN
	renew until 12/13/07 18:06:26

Now, let’s try to log in into the OpenSSH server. Kerberos/GSSAPI authentication should be negotiated, as shown by the debugging information:

core2:~ falfaro$ ssh -v solana
OpenSSH_4.5p1, OpenSSL 0.9.7l 28 Sep 2006
debug1: Reading configuration data /Users/falfaro/.ssh/config
debug1: Applying options for *
debug1: Reading configuration data /etc/ssh_config
debug1: Connecting to solana [10.42.242.12] port 22.
debug1: Connection established.
debug1: identity file /Users/falfaro/.ssh/id_rsa type -1
debug1: identity file /Users/falfaro/.ssh/id_dsa type 2
debug1: Remote protocol version 2.0, remote software version OpenSSH_4.5
debug1: match: OpenSSH_4.5 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.5
debug1: Offering GSSAPI proposal:
 gss-gex-sha1-toWM5Slw5Ew8Mqkay+al2g==,
 gss-group1-sha1-toWM5Slw5Ew8Mqkay+al2g==,
 gss-group14-sha1-toWM5Slw5Ew8Mqkay+al2g==,
 gss-gex-sha1-A/vxljAEU54gt9a48EiANQ==,
 gss-group1-sha1-A/vxljAEU54gt9a48EiANQ==,
 gss-group14-sha1-A/vxljAEU54gt9a48EiANQ==,
 gss-gex-sha1-bontcUwnM6aGfWCP21alxQ==,
 gss-group1-sha1-bontcUwnM6aGfWCP21alxQ==,
 gss-group14-sha1-bontcUwnM6aGfWCP21alxQ==
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'solana' is known and matches the RSA host key.
debug1: Found key in /Users/falfaro/.ssh/known_hosts:8
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue:
 publickey,gssapi-keyex,gssapi-with-mic,password,keyboard-interactive
debug1: Next authentication method: gssapi-keyex
debug1: No valid Key exchange context
debug1: Next authentication method: gssapi-with-mic
debug1: Authentication succeeded (gssapi-with-mic).
debug1: channel 0: new [client-session]
debug1: Entering interactive session.
Last login: Thu Dec  6 20:29:59 2007 from foo.lan
$ hostname
ssh.lan
$ exit
logout
Connection to solana closed.

If we run klist again, we will see that, in addition to the TGT we saw before, we will see the Kerberos service ticket for the OpenSSH server:

Kerberos 5 ticket cache: 'API:Initial default ccache'
Default principal: alice@LAN

Valid Starting     Expires            Service Principal
12/06/07 18:06:26  12/07/07 04:06:26  krbtgt/LAN@LAN
	renew until 12/13/07 18:06:26
12/06/07 18:07:27  12/07/07 04:06:26  host/ssh.lan@LAN
	renew until 12/13/07 18:06:26

8. Troubleshooting

The GSSAPI authentication mechanism is very picky about many things, and error codes and messages are usually very cryptic but not very helpful about what the cause of the error is.

I found that acommon source of authentication problems are entries in /etc/hosts confusing GSSAPi about the host name. For example, entries like this in /etc/hosts:

192.168.0.1  ssh ssh.lan

can cause SSH to think the host name is ssh instead of the expected FQDN — ssh.lan.The previous entry causes reverse name resolutions for IP 192.168.0.1 to return ssh as the host name, but not ssh.lan. Since the Kerberos keytab is host/ssh.lan but IP 192.168.0.1 is resolved to ssh this may cause authentication attempts to fail because no Kerberos keytab for host/ssh exists in /etc/krb5.keytab. The most common symptom is trying to SSH to localhost, getting a failed authentication and but ticket for the target host. Example:

$ kinit
Password for alice@LAN: 

$ klist
Ticket cache: FILE:/tmp/krb5cc_501
Default principal: alice@LAN

Valid starting     Expires            Service principal
05/31/09 01:08:21  06/01/09 01:08:20  krbtgt/LAN@LAN

Then,

$ ssh ssh.lan
alice@ssh.lan's password:

But no Kerberos ticket for ssh.lan was even requested:

$ klist
Ticket cache: FILE:/tmp/krb5cc_501
Default principal: alice@LAN

Valid starting     Expires            Service principal
05/31/09 01:08:21  06/01/09 01:08:20  krbtgt/LAN@LAN

One possible solution consists of removing the matching entry from /etc/hosts, provided that the existing DNS name server can properly resolve the IP address of the server to the correct FQDN. If this is not possible, another solution is making sure the FQDN name is listed before the non-FQDN name in the corresponding line in /etc/hosts.

8. References

Some additional and very useful references:

• Kerberos 5 setup for NFSv4.

  Describes common pitfalls, like using a non-FQDN host name in /etc/hosts or not using clock synchronization.

Introducción

En los sistemas convencionales, el votante se dirige a un colegio electoral, introduce su voto, en forma de papeleta, en un sobre, se identifica ante un agente e introduce su voto en una urna. Los sistemas tradicionales separan el proceso de autentificación del votante del proceso recuento de votos, de forma que éstos se realizan de forma independiente.

El proceso de autentificación no tiene acceso al contenido del voto y sirve meramente para evitar que sólo los individuos autorizados puedan ejercer su derecho al voto. Así mismo, el proceso de autentificación es capaz de evitar votos duplicados, es decir, la emisión del mismo voto más de una vez por el mismo individuo, y también es capaz de ofrecer el cómputo de votos recibidos y calcular estadísiticas como el porcentaje de votos recibidos sobre el total de la población con derecho a voto.

El modelo tradicional confía en que el proceso de autentificación fue correctamente realizado, que el transporte entre el sistema de autentificación y el sistema de recuento es fiable (no hay pérdida de datos, ni manipulación del canal, como la eliminación de votos, etc.) y que el registro de los votos no fue alterado. El proceso de recuento es capaz de clasificar el conjunto total de los votos según su contenido, normalmente en un número discreto, finito y normalmente reducido de posibilidades.

Se desea una implementación de sistema de voto electrónico que permita la autentificación del votante a la vez que mantenga el anonimato del voto, conservando la semántica de los sistemas de voto tradicionales.

Presentación

Se propone una solución de voto electrónico en la que intervienen tres entidades:

• El votante
• Un sistema de autentificación
• Un sistema de recuento o registro de votos

El voto se introduce en un sobre, cuyo destinatario final es el sistema de recuento. Este sobre, a su vez, se introduce en otro cuyo destinatario final es el sistema de autentificación. El voto, encapsulado en dos sobres, pasará por los dos sistemas. Primero por el sistema de autentificación que comprobará la identidad del votante, así como que el votante no haya votado ya alguna vez. El sistema de autentificación no tendrá acceso al segundo sobre, que contiene el voto en sí mismo. De esta forma, el voto se oculta del sistema de autentificación. Una vez autentificada la identidad del votante, y sin conocer el contenido del voto, el segundo sobre se envía al sistema de recuento que registrará el voto. El sistema de autentificación elimina la firma digital del votante y la sustituye por la suya a fin de permitir el voto anónimo.

El objetivo del entorno es que el sistema de autentificación no tenga acceso al voto en sí mismo (anonimato) pero pueda validar la identidad del votante, y que el sistema de recuento tenga acceso al voto en sí mismo pero no a la identidad del votante.

Para ello, se propone el siguiente sistema basado en criptografía de clave pública:

Premisas

El votante sólo conoce K_EV, K_DV (su pareja de claves pública y privada) así como K_EA y K_ER. El sistema de autentificación sólo conoce K_EV, así como K_EA, K_DA (su pareja de claves pública y privada) y K_ER. El sistema de recuento sólo conoce K_EA, así como K_ER y K_DR (su pareja de claves pública y privada).

Implementación

A la hora de emitir su voto electrónico, el votante emite el siguiente mensaje, destinado al sistema de autentificación:

Una vez en posesión de M_V, el sistema de autentificación puede validar la firma digital de M_V descrifándolo con la clave pública del votante, K_EV, y obteniendo:

El sistema de autentificación puede validar la autenticidad del votante, pero sin tener acceso al contenido del voto en sí mismo, V, al no tener el sistema de autentificación acceso a K_DR. El sistema de autentificación debe establecer que ID_V coincide con la identidad del votante (por ejemplo, su NIF). En ese caso, el sistema de autentificación validará que el votante V no haya votado con anterioridad, comprobando que la estampa de tiempo TS₁ no difiera de la estampa horaria actual en más de un periodo determinado como seguro (por ejemplo, 48 horas). Si la identidad del votante no puede ser comprobada o la estampa horaria TS₁ está fuera del intervalo permitido, el mensaje se descarta. En caso contrario, el sistema de autentificación emite el siguiente mensaje, M_A, destinado al sistema de recuento:

El sistema de recuento deberá verificar la firma digital de M_A. De ser correcta, el sistema de recuento tendrá acceso a:

De no ser correcta, el mensaje M_V será descartado. El sistema de recuento comprobará que TS₁ = TS₂ ±εy que tanto TS₁ como TS₂ estén dentro de unos márgenes de tiempo aceptables. En ese caso, se podrá proceder a obtener el voto V y registrarlo en un sistema de almacenamiento que sea tamper-resistant (resistente a modificaciones maliciosas o no autorizadas).

Al diferencia de los sistemas tradicionales, donde los votos se acumulan en su totalidad en el sistema de autentificación hasta el cierre de la recepción de votos, el modelo descrito permite dos posibilidades:

• Acumulación previa:

  Una vez se finalice la admisión de votos, el sistema puede enviar el conjunto de todos los M_A acumulados, más el cardinal de dicho conjunto, como un mensaje único firmado digitalmente por el sistema de autentificación.

  Esto ofrece una reducción en la posibilidad de que un agente externo pueda manipular el canal de comunicación entre el sistema de autentificación y el de recuento, invalidando la votación. A su vez, hace que un agente externo pueda invalidar la votación con tan sólo manipular el estado del sistema de autentifcación. Se disminuye el riesgo de compromiso del canal, pero se aumenta el riesgo en caso de compromiso del sistema de autentificación.

• Envío inmediato:

  Esto ofrece una reducción en la posibilidad de que un agente externo pueda manipular el estado del sistema de autentificación (al ser un sistema store-and-forward, el estado se reduce al mínimo), invalidando la votación. A su vez, hace que un agente externo pueda invalidar la votación con tan sólo manipular el canal de comunicaciones mediante la eliminación selectiva de mensajes. Se disminuye el riesgo de compromiso del estado del sistema de autentificación, pero se aumenta el riesgo en caso de compromiso del canal de comunicaciones.

Particularmente, creo que la segunda opción es la más aconsejable: es más sencillo delegar la seguridad del canal de comunicaciones a protocolos como IPSec y la correcta secuenciación de mensajes a TCP que implementar la seguridad en el propio protocolo de voto electrónico.

Autentificación del votante y anonimato del voto

La seguridad del sistema estriba en que el sistema de recuento desconoce la identidad del usuario que emitió el voto V (ID_V), y a la vez que se asegura la autenticidad de éste al ser cada voto anónimo autentificado por el sistema de autentificación. A su vez, el sistema de autentificación sólo tiene acceso a la identidad del usuario que emitió el voto V (ID_V), pero no al contenido de su voto.
La seguridad del sistema depende en la relación de confianza del sistema de recuento sobre el sistema de autentificación, así como la capacidad del sistema de autentificación para validar la identidad ID_V del votante correctamente, y la capacidad del sistema de recuento para almacenar el recuento de votos de manera que no se pueda manipular maliciosamente.

El modelo descrito sólo es capaz de detectar si el contenido de un voto es inválido en el sistema de recuento. Llegado a este punto, y dado que este sistema no tiene acceso a la identidad del votante, lo único que puede hacer es marcar el voto como inválido. El modelo descrito permite, por lo tanto:

• Voto válido
• Voto en blanco
• Voto inválido

Será necesario determinar si estas características son deseables a la hora de aplicar el modelo aquí descrito.

The firewall in Mac OS X 10.5 Leopard is confusing, to say the least. It is not enabled by default, which is a huge mistake, in my humble opinion. Also, the graphical user interface offers less flexibility than in previous version while trying to configure it. Besides allowing you to independently control the blocking of incoming ICMP Echo Requests and logging via syslog, it has the following main operation modes:

• Allow all incoming connections.

  Seems obvious that choosing this setting means that the firewall is essentially disabled and any traffic can freely flow in and out of the computer.

  I would not recommend this setting, even for trusted networks. It is easy for a laptop computer to attach to a different network at any time and have the user forget to re-enable the firewall, posing as a potential victim for other users or computers. For a desktop computer it is more and more common to be attached to a network that has some sort of wireless bridging or routing device that might be used by untrusted users to get access to the network, or by trusted users that carry (maybe without their knowledge) malware, for example.

  This setting offers little or no security, but makes very easy to share contents or provide external services.

• Block al incoming connections.

  This seems the safest choice, but might not always be desirable if you are sharing content or have services running that you want to make accessible from the outside (like an SSH server, or even the iTunes music collection).

  This is my preferred setting, I have to say. This setting offers adequate security, but stops you from sharing content or offering access to services externally. However, it seems that Leopard’s firewall does not block all services, and some of them are still accessible from the outside (see at the end of the post for more information).

• Set access for specific services and applications.

  This is by far the most confusing setting. First, because it doesn’t seem to add any rules to IPFW. I’m starting to believe that Leopard offers two layers of filtering. It seems IPFW is one of them, but it defaults to use a ruleset with only default accept entry in it (sequence 65535):

  # ipfw list
  65535 allow ip from any to any
  

  (NOTE: if you enable the Stealth functionality, a IPFW rule is added before the default entry, and it looks like this:

  33300 deny icmp from any to me in icmptypes 8
  

  This blocks ICMP Echo Requests, but be aware that Stealth mode is not enabled by default).

  About the other filtering layer, I’m not sure what it is used or how it is implemented, but it seems to be the result of some sort of kernel-level and user-space cooperation. The second reason why I think this setting can be confusing is because it seems to only affect a particular user (normally the logged user), but not the system or other users like root.

  For example, I compiled synergy and ran it as user root. Then, I configured the Leopard’s firewall for access to specific services and applications, but I left the list empty. I verified that I could reach the synergys server at port 24800 from other computer in the same network segment. I was really surprised, to be honest.

  The next thing I tried is to kill synergys and to re-run it as my currently logged in user. This time, Leopard presented me with a dialog box that asked whether to allow synergys to accept incoming connections:

  Do you want the application “synergys” to accept incoming network connections?

  Clicking Deny may limit the application’s behavior. This setting can be changed in the Firewall pane of Security Preferences.

  This caused the expected behavior: any attempt to connect to port 24800 from the outside was blocked by Leopard’s firewall:

  22:02:30.989097 IP 10.42.242.16.49950 > 10.42.242.12.24800:
    S 3207271609:3207271609(0) win 65535
    <mss 1460,nop,wscale 3,nop,nop,timestamp 699234003 0,sackOK,eol>
  22:02:31.913244 IP 10.42.242.16.49950 > 10.42.242.12.24800:
    S 3207271609:3207271609(0) win 65535
    <mss 1460,nop,wscale 3,nop,nop,timestamp 699234012 0,sackOK,eol>
  22:02:32.914300 IP 10.42.242.16.49950 > 10.42.242.12.24800:
    S 3207271609:3207271609(0) win 65535
    <mss 1460,nop,wscale 3,nop,nop,timestamp 699234022 0,sackOK,eol>
  22:02:33.915334 IP 10.42.242.16.49950 > 10.42.242.12.24800:
    S 3207271609:3207271609(0) win 65535
    <mss 1460,sackOK,eol>
  22:02:34.916398 IP 10.42.242.16.49950 > 10.42.242.12.24800:
    S 3207271609:3207271609(0) win 65535
    <mss 1460,sackOK,eol>
  22:02:35.917319 IP 10.42.242.16.49950 > 10.42.242.12.24800:
    S 3207271609:3207271609(0) win 65535
    <mss 1460,sackOK,eol>
  22:02:37.919629 IP 10.42.242.16.49950 > 10.42.242.12.24800:
    S 3207271609:3207271609(0) win 65535
    <mss 1460,sackOK,eol>
  22:02:41.924491 IP 10.42.242.16.49950 > 10.42.242.12.24800:
    S 3207271609:3207271609(0) win 65535
    <mss 1460,sackOK,eol>
  

  Note how the first three segments had the time-stamp and window scaling options activated. The remaining SYN segments didn’t. This is probably due to Leopard thinking that there was congestion or that it was talking to an old system.

  Once I chose Always allow, Leopard added an entry into the Firewall list named synergys. From here on, I was able connect to port 24800. This is the the network capture that tcpdump displayed when trying to connect to port 24800 from another compuer after synergys had been granted access:

  22:24:20.674656 IP 10.42.242.16.50055 > 10.42.242.12.24800:
    S 2514913060:2514913060(0) win 65535
    <mss 1460,nop,wscale 3,nop,nop,timestamp 699247086 0,sackOK,eol>
  22:24:20.675544 IP 10.42.242.12.24800 > 10.42.242.16.50055:
    S 812848149:812848149(0) ack 2514913061 win 65535
    <mss 1460,nop,wscale 1,nop,nop,timestamp 473026159 699247086,sackOK,eol>
  22:24:20.675591 IP 10.42.242.16.50055 > 10.42.242.12.24800:
    . ack 1 win 65535 <nop ,nop,timestamp 699247086 473026159>
  22:24:20.677911 IP 10.42.242.12.24800 > 10.42.242.16.50055:
    P 1:16(15) ack 1 win 33304 <nop ,nop,timestamp 473026159 699247086>
  22:24:20.677959 IP 10.42.242.16.50055 > 10.42.242.12.24800:
    . ack 16 win 65535 <nop ,nop,timestamp 699247086 473026159>
  

  Funny enough, keeping my telnet client running while trying to connect at port 24800, waiting for Leopard to remove the time-stamp and window scaling options, then allowing this traffic, didn’t make Leopard to try to re-negotiate the time-stamp and window scaling options.

  Another thing worth mentioning is that once synergys had been granted access to incoming traffic at port 24800, removing it from the list of allowed applications and services didn’t stop it from receiving traffic. To block synergys from receiving traffic it was necessary to change Allow incoming connections to Block incoming connections (removing its entry from the list did still allow it to receive incoming traffic).

  Another interesting feature is that Leopard’s seems to be aware of service dependency. For example, enabling the Screen Sharing service also starts a local Kerberos 5 KDC which is used to authenticate users. This is fascinating since users of Screen Sharing, for example, will first request a TGT to this local Kerberos 5 KDC (and will be able to decrypt that TGT if they know the correct password), then using the TGT request a service ticket for the Screen Sharing service that can present to it in order to get authenticated. But moreover, trying to connect to the Screen Sharing service for a second time will not require the user to provide his credentials again because a Kerberos service ticket is already available (provided that it didn’t expire). This is Single Sign-On in its true form.

Conclusion

In conclusion, I can’t say that the graphical user interface provides a lot of room for configuration, neither does it offer any way to configure egress filtering (that is, traffic that originates on the local computer and is to be sent out externally via a network interface).

In general, Leopard’s default administration tools are probably on par with those from Windows Vista. Even though the underpinnings of the newest member of the Mac OS X family are powered by IPFW, I feel Leopard’s firewall has a long way to go to in order to get closer to the powerful functionality and configurability of PF or Netfilter/IPtables, for example.

Also, not enabling the firewall by default is a big mistake in my opinion. One of my Mac OS X laptops is listening on port 111/tcp, 1020/tcp and 1021/tcp. The first one is iCalAlarmAgent and the other two are related to launchd. Even if you configure the firewall to block all traffic, these three ports are still accessible from the outside.

Once again, it’s good to know that some Web sites are treating sensitive information, like user credentials, the way they deserve: in plain-text.

I saw the following error message from the VMware site while trying to log in:

Fatal error: Uncaught exception ‘Exception’ with message ‘SimpleXMLElement::__construct() expects parameter 1 to be string, object given’ in /www/html/beta_programs/methods.class.php:154 Stack trace: #0 /www/html/beta_programs/methods.class.php(154): SimpleXMLElement->__construct(Object(SOAP_Fault)) #1 /www/html/beta_programs/methods.class.php(61): methods->verifyStoreSoap(‘felipe_alfaro@m…’, ‘straussered’) #2 /www/html/beta_programs/request_process.php(88): methods->login(‘felipe_alfaro@…’, ‘my_password’) #3 {main} thrown in /www/html/beta_programs/methods.class.php on line 154

Isn’t this amazing that they are making SOAP requests passing user credentials in plain-text? At least, I have some confidence they are using SOAP over SSL