Me complace compartir el I Journal “Safe and free” 2025, un nuevo evento en línea para seguir difundiendo y divulgando el Software Libre para todo el mundo. Una jornada con 4 ponentes hablando de 4 temas, tanto para usuarios noveles como a avanzados.

I Journal “Safe and free” 2025

El pasado mes de noviembre de 2024 se celebró el III Seminario Anual GNU/Linux. De esta forma todos los fines de semana de noviembre tuvimos una cita con el mundo GNU/Linux en forma de ponencias en directo con divulgadores de todo el mundo hispano hablante con la nueva edición del seminario Anual GNU/Linux.

De esta forma, la Comunidad OpenShield organizó 8 presentaciones con las que iniciarse, aprender, profundizar y, en general, conocer un poco más el abanico de posibilidades que te ofrece el mundo del Conocimiento Libre al módico precio de un poco de tu tiempo (que no es poco).

El objetivo de este evento era mostrar, enseñar y demostrando las bondades de Linux, GNU/Linux, objetivo que se repite es mes de julio en forma de única jornada.

De esta forma os me complace compartir con vosotros que la Academia GNULinux os trae el I Journal «Safe and free» 2025, la cual constara de 4 ponencias de acuerdo al siguiente detalle:

• Baltasar Ortega: Novedades en Plasma 6.4, mejorando el escritorio de la comunidad KDE
• Klaibson Ribeiro: Mi IA, Mis Reglas, Como Onlyoffice trabaja con IA
• José Flores: Deshabilitar cifrados débiles SSH en GNU/Linux
• Angelo Ramirez: Seguridad en thunderbird

Las charlas serán de 25 minutos cada una, con 10 minutos de diferencia entra una y otra. Os esperamos.

IMPORTANTE: La hora está referida a la de Perú, para la península Ibérica se empieza a las 21:00 horas, una menos en canarias.

La entrada I Journal “Safe and free” 2025 se publicó primero en KDE Blog.

Me complace compartir el I Journal “Safe and free” 2025, un nuevo evento en línea para seguir difundiendo y divulgando el Software Libre para todo el mundo. Una jornada con 4 ponentes hablando de 4 temas, tanto para usuarios noveles como a avanzados.

I Journal “Safe and free” 2025

El pasado mes de noviembre de 2024 se celebró el III Seminario Anual GNU/Linux. De esta forma todos los fines de semana de noviembre tuvimos una cita con el mundo GNU/Linux en forma de ponencias en directo con divulgadores de todo el mundo hispano hablante con la nueva edición del seminario Anual GNU/Linux.

De esta forma, la Comunidad OpenShield organizó 8 presentaciones con las que iniciarse, aprender, profundizar y, en general, conocer un poco más el abanico de posibilidades que te ofrece el mundo del Conocimiento Libre al módico precio de un poco de tu tiempo (que no es poco).

El objetivo de este evento era mostrar, enseñar y demostrando las bondades de Linux, GNU/Linux, objetivo que se repite es mes de julio en forma de única jornada.

De esta forma os me complace compartir con vosotros que la Academia GNULinux os trae el I Journal «Safe and free» 2025, la cual constara de 4 ponencias de acuerdo al siguiente detalle:

• Baltasar Ortega: Novedades en Plasma 6.4, mejorando el escritorio de la comunidad KDE
• Klaibson Ribeiro: Mi IA, Mis Reglas, Como Onlyoffice trabaja con IA
• José Flores: Deshabilitar cifrados débiles SSH en GNU/Linux
• Angelo Ramirez: Seguridad en thunderbird

Las charlas serán de 25 minutos cada una, con 10 minutos de diferencia entra una y otra. Os esperamos.

IMPORTANTE: La hora está referida a la de Perú, para la península Ibérica se empieza a las 21:00 horas, una menos en canarias.

La entrada I Journal “Safe and free” 2025 se publicó primero en KDE Blog.

Sigo con la séptima entrada de este año de la iniciativa #viernesdeescritorio. Bienvenidos a mi escritorio Plasma de julio 2025, realizado sobre ordenador portátil, un Slimbook Pro, con el que llegamos a las 62 entregas compartiendo «Mi escritorio» de forma mensual (ya son muchos meses que mi troll no me visita. No lo echo de menos).

Mi escritorio Plasma de julio 2025 #viernesdeescritorio

Esta va a ser la sexagésimasegunda (62 para los que nos cuesta leer esto) vez que muestro mi escritorio Plasma 6 en público, lo cual es número nada desdeñable de entradas que sigue creciendo de forma constante.

De nuevo lo realizo de nuevo sobre mi Slimbook Pro, el cual tiene instalado un KDE Neon con Plasma 6.4.2, sobre una versión de KDE Frameworks 6.15.0 y una versión de Qt 6.9.0. El servidor gráfico es Wayland y el Kernel es 6.11.0-29-generic (64 bits).

En este equipo utilizo un aspecto bastante muy oscuro, con el tema global básico Brisa Oscuro e iconos estándar (Brisa Oscuro). La barra de tareas a la izquierda se ha quedado para siempre. En ella he puesto un plasmoide llamado Weather Widget Plus, bajo del reloj de la barra de tareas, que me indica la temperatura del exterior de mi casa y me hace la previsión para unos días. Ade,ás, abajo he puesto selector de colores y un pequeño bloc de notas.

Para el fondo tengo una novedad: he puesto un widget llamado Random AI Wallpaper que me pone un fondo aleatorio, generados por alguien gracias a la IA y de calidad (la IA puede genera fondos pero que sean de calidad es decisión de una persona), y que se guardan en un Gitlab. Pronto en el blog.

Y para finalizar, he cambiado mi reloj de escritorio por otro creado por una desarrollador de Plasma que me indica la hora aproximada, que queda estupendo en temas oscuros. Una maravilla y, además, es exclusivo.

El resultado de mi escritorio Plasma de julio de 2025 es un entorno de trabajo oscuro y, como siempre, funcional que podéis ver en la imagen inferior (pinchad sobre ella para verlo un poco más grande).

La entrada Mi escritorio Plasma de julio 2025 #viernesdeescritorio se publicó primero en KDE Blog.

Comparto en el blog la respuesta de la defensora del oyente sobre el bloqueo a aplicaciones de terceros a los podcasts de RTVE y RNE. Spoiler: No son buenas noticias

Ayer mismo publiqué en el blog un artículo sobre mi experiencia a la hora de reproducir podcasts de la radio pública del estado español.

• https://victorhckinthefreeworld.com/2025/07/16/rtve-bloquea-sus-podcats-a-la-aplicacion-antennapod/

En el artículo describía cómo desde hace unos días o semanas, mi reproductor de podcasts en el móvil no podía reproducir los podcats públicos creados por un medio público y estatal como es Radio Naciona del España (RNE).

Y también comenté que había expresado mi queja a la defensora del oyente sobre el hecho de que desde el medio público se coartase de esa manera el acceso a su contenido (contenido público realizado con dinero público).

Pues bien, la defensora del oyente ha respondido, y la respuesta que ha dado (nada nuevo) no te va a gustar.

Primero comparto la queja que le envié:

Hola.
Desde hace un tiempo vengo comprobando que mi reproductor de podcasts en Android no funcionaba con los podcasts de RTVE. Estoy suscrito a unos cuantos, por ejemplo: El sótano de RNE3, Raíz de 5 de RNE5, y algunos otros. Pero mi reproductor funciona correctamente con otros podcasts, por ejemplo de la SER, y otros independientes.
Al principio lo achacaba a un problema de conexión o similar, después de comprobar varias cosas durante días, veo que parece ser que la web de RTVE rechaza los podcasts escuchados con cierta aplicación de software libre que es la que utilizo para escuchar mi colección de podcasts.
Es decir, RTVE, está en contra de la neutralidad de la red al coartar el contenido público usando ciertas herramientas. El medio público ofrece su contenido, pero con restricciones para ciertos usuarios. Pero no del todo, porque desde mi portátil sí puedo escuchar los podcats sin problema.
¿Hay alguna causa que justifique dicho comportamiento selectivo?

A continuación comparto la respuesta de la defensora del oyente a mi queja:

Gracias por escribirnos.

Lamentamos su malestar. Desde la Subdirección de Innovación y Productos Digitales de RTVE nos aportan la siguiente explicación sobre este asunto por el que nos han preguntado muchos usuarios como usted en esta Oficina de la Defensora:

"A partir de ahora, la descarga de audios solo está habilitada desde la aplicación oficial de RNE para garantizar la calidad, la correcta atribución del contenido y el cumplimiento de los derechos de autor y de difusión.
Permitir la descarga desde aplicaciones de terceros (no oficiales) dificultaría asegurar que los contenidos se distribuyan con la calidad y el contexto adecuados, además de poder vulnerar los acuerdos editoriales y de derechos que protegen tanto a los creadores como a la propia emisora.
Esta medida responde a dos motivos principales: por un lado, no podemos conocer ni contabilizar el uso real de nuestros contenidos en esas plataformas, lo que dificulta ofrecer un servicio de calidad y valorar correctamente el alcance. Por otro, el consumo a través de terceros genera un coste directo para RNE (especialmente en términos de CDN), sin ningún beneficio asociado ni control sobre la experiencia del usuario.
Por ello, para garantizar un servicio sostenible y de calidad, los contenidos solo estarán disponibles para descarga y escucha dentro de RNE Audio y en aquellas plataformas con las que exista un acuerdo".
Le agradecemos su interés y participación.
Reciba un cordial saludo.

Lo que entiendo es que a partir de ahora RNE únicamente permitirá el acceso a los podcats de su programación desde la aplicación oficial de RNE.

El contenido es público y pagado con dinero público (vuelvo a recalcar ese hecho) pero sólo podremos hacerlo desde su aplicación desarrollada con dinero público y que no es software libre y solo está disponible en plataformas privativas (nada de f-droid).

También entiendo que igual que en mi portátil por medio de Amarok, estaba suscrito a los podcasts para oirlos en mi equipo, tampoco esto será posible a partir de ahora, teniendo que acceder a su web y reproducirlos desde su reproductor en su página.

Es totalmente injusto que un medio público utilice un medio de difusión público como son los podcats y lo encierre no permitiendo el libre acceso a su contenido.

Las excusas son el poder tener un control de las descargas, acuerdos editoriales, derechos de autor, coste extra para RNE.

¿De verdad con una herramienta de terceros no tienen un acceso al número de descargas de cada audio para tener una trazabilidad de lo más escuchado?

Sobre las demás excusas para imponer ese recorte a la hora de difundir su contenido no tengo más comentarios, con los derechos de autor hemos topado. De acuerdo que hay que proteger esos derechos de autor, pero me temo que más que querer proteger al autor, lo que quieren es proteger a quien gana dinero con el contenido creado con el autor, que no siempre es bien pagado.

Por tanto, ya lo sabes. A partir de ahora parece ser que sólo podrás escuchar sus audios desde la aplicación oficial, su web o aquellas aplicaciones con las que hayan llegado a un acuerdo.

¿Quizás pronto su programación en directo por radio en FM sólo estará disponible para los receptores de radio que ellos aprueben y con los que lleguen a un acuerdo? ¿qué más restricciones tiene en mente un medio público a la hora de difundir su contenido? Lo veremos en próximas entregas.

Si vuestra aplicación de podcats también se ha visto afectada por esta restricción, que parece ser que pronto serán todas, menos las aprobadas por el ente, podéis también enviar una queja y ver si el medio cambia de opinión…

• https://www.rtve.es/rtve-responde/participacion/

openSUSE have now multiple ways to configure a Full Disk Encryption (FDE) installation. A very secure and easy way (YaST2) of doing this is via user space tools, as we described multiple times (like here, here, or here). This solution is based on the systemd tool-set like systemd-cryptenroll, systemd-pcrlock and systemd-cryptsetup, among other, orchestrated by the in-house sdbootutil script.

One of the main advantages of using this systemd approach is the possibility of integrating multiple authentication methods. Together with the traditional password, asked at boot time during the initrd stage, we can now unlock the system using a certificate, a TPM2, or a FIDO2 key. We can mix some of them creating multiple LUKS2 key slots, and use, for example, a TPM2 to unlock the device in a unattended fashion and a FIDO2 key as a recovery mechanism.

Honestly, the TPM2, and the TPM2+PIN variation, are the most relevant ones for the user. As described in the other posts, the TPM2 is a (some times virtual) device that can attest the health of our system using a mechanism known as measured boot.

The tl; dr version of this is that each stage of the boot process, starting from the firmware, will load and “measure” the next stage before delegating the execution on it. For example, this means that there is a moment in the latest stages of the boot process where the UEFI firmware will load from the disk the boot loader into memory. This can be the shim, systemd-boot or grub2-bls. It will calculate a hash value (usually SHA256) and will command to the TPM2 an “extend” operation for one of the internal register (PCR).

The extension is a cryptographic computation that is very easy to calculate, but impossible to replicate. It is done to one of those internal registers (PCR) and consist of calculating the hash (again SHA256) of the old value of the PCR together with the hash of the component that we are measuring. This new value will replace the current PCR value, as is the only way to change those registers. The security property resides in that it is cryptographically impossible to force the write of a desired value on one of those PCRs, but very easy to calculate the final value.

So this means that if all the components of the boot chain process are measured (all the stages in the UEFI firmware, the firmware configuration, the boot loader, the command line, the kernel and even the initrd), the final PCRs values can be compared with our expectations, and discover if the system has been booted with a good known software and configuration, allowing us to instantly known if some component in the boot chain has been hacked or modified with out consent.

That is a powerful property to have, but what is more interesting is that we can have secrets that can only be open in case that we are in one of those good or recognized states. We can, for example, cipher (seal) the key that open an encrypted disk using the TPM2, together with a policy that will decipher (unseal) the same key only, and only if we are using the same TPM2 and the PCR values are on a list of expected ones. Those policies can be very complicated, and can include extra passwords, certificates or other checks that will be validated before the TPM2 can unseal the key.

With a mechanism like this in place, thanks to the systemd tools, we can now avoid entering the password to unlock the encrypted disk if the system is in a healthy state. Healthy in the sense that we cryptographically guarantee that the code and configurations used during the boot process are the expected one, and no one entered init=/bin/bash in our kernel command line, or replaced the kernel or initrd with a vulnerable one, for example.

With the integration that we made of this model in openSUSE, we can make updates of the system, including the boot loader or the kernel, and sdbootutil will transparently generate new predictions of expected PCR values that are now considered safe. This imply an update of the TPM2 policy, that will be taken into consideration for the next boot, so the automatic unlock will succeed. If something goes wrong and the expected PCR values are not meet, the user will need to enter the password that is stored in a different LUKS2 key slot to open the device, to audit the system and validate it.

The fault in the design

Using a TPM2 as described before is a clear increase in the security level, but it is not the final answer. Security is always asymptotic approximation.

Some years ago a physical attack was described for the Windows BitLocker FDE solution. BitLocker is also using the TPM2 in a similar way that was described before, but was not using encrypted session to communicate with the device. Intercepting the SPI bus was shown possible to recover the password that unlock the disk. systemd learned from that and used encrypted sessions early, but this attack can also be avoided if the policy used to unseal the key was also demanding a PIN or password that must be entered by the user. Now the TPM2 can only unseal the secret if the PCRs are in the correct state and the provided password is the correct one. Should be noted that AFAIK the SPI sniffing can work with Clevis.

But more recently a second attack was made public that fully affect the original proposal, and does not requires the sophistication of the original one. (Disclosure: the attack was also internally described independently months before and some counter measurements was put in place much early)

The article describes how that attack can be done checking in the initrd the filesystem UUID used to mount the encrypted device. This information is inside the /etc/crypttab stored in the initrd, that will do something like this:

systemd-cryptsetup attach cr_root /dev/disk/by-uuid/$UUID 'none' 'tpm2-device=auto'

If the expected firmware, configuration files, kernel and initrd are used during the boot process then the TPM2’s PCRs registers will have values that match the policy that unlock the device and the sealed key can be now unsealed by the TPM2, the disk will be unlocked, the switch root will succeed and the boot process will continue in the rootfs.

But what if the original drive is replaced by one that has the same UUID (it is a public information after all) that is also encrypted? Then the PCRs will be in the same correct state. Note that in measure boot is the previous stage the one that measures the next one before delegating the execution. Then systemd-cryptsetup will try to use the TPM2 to unlock the device using the key successfully unsealed by the TPM2 and … will fail to open it, of course. The rogue device maybe have a TPM2 key slot in the LUKS2 header, but for sure cannot be open with this TPM2 nor with the secret password.

In this situation systemd-cryptsetup will ask for the password to unlock the device, and the attacker can enter one that this time will open the rogue device. The switch root will happen but now it will continue the boot process in the fake rootfs, and a program stored there can make questions to the TPM2, that still contains the good PCR values. One of the questions can be the unseal of the secret key using the current policy. And this time (as was done before), the TPM2 will agree to deliver the secret to the bad program. Game over.

There are solutions for this attack, of course.

One is again to use TPM2+PIN instead of TPM2, the same solution for the sniffing attack. In this case the first systemd-cryptsetup call will fail and a password will be asked to unlock the device. But now the bad program cannot ask to the TPM2 to unseal the device using the current policy. The PCR values will match, but the policy also requires the enter of a secret PIN or password known by the real user, and without it the unseal will fail and the key will be keep safe.

Another solution is somehow invalidate the policy, extending some of the PCRs involved before the switch root, so the policy cannot be applied anymore after that. This can be done automatically by systemd-cryptsetup using the measure-pcr=yes in /etc/crypttab. With this option PCR15 will be extended using the volume key, a secret that can only be extracted knowing some of the device keys. For this solution to work, PCR15 needs to be included in the current policy, with an expected value of 0x000..00, the default one. Once the rogue device is open by the hacker provided password, PCR15 will be automatically extended and the value will be different from 0x000..00, invalidating the policy before the switch root.

That is a good solution, but not for us. In the daily situation the user will need to update the system, and a new policy needs to be calculated to replace the old one (for example when the kernel is updated). Because with systemd-pcrlock the policy is stored in the TPM2 in one of the Non Volatile RAM slots (NVIndex), we need to protect it somehow, so it cannot be replaced by other process. For that systemd is storing a secret key (recovery PIN) in a different NVIndex that is sealed by the same policy! If the key cannot be automatically recovered, because the policy does not apply anymore, then the recovery PIN will be asked to the user, making the update process a bit unpleasant if the policy is always invalidated.

Finally, another way to address the issue is to stop the boot process if we detect that the device is not the expected one. We can think of a new service, living in initrd that is executed in the very last moment, just before the switch root, that can stop the boot process (maybe halting the system) if the device that stores the rootfs is not the expected one.

For this, PCR15 is still a good solution. It contains the measurement of a secret (volume key) that can only be known by the real user, and cannot be replicated by the attacker. Ideally we can create a prediction for PCR15 and make this service to compare the effective value with the expected one, and if they are different then it can stop the boot process.

This is what the measure-pcr-validator service from sdbootutil is doing. sdbootutil first generates a prediction for all the encrypted devices that are opened during the initrd, and check that the correct tag is present in /etc/crypttab. To be able to access the volume key, the tool needs the root password, so this prediction is only update when it is really necessary, like for example when a new encrypted device is added. This prediction is signed by a private key stored in the host, as an extra security measurement, but because the public key is also stored in the ESP it is honestly not adding too much.

An extra service (measure-pcr-generator) will put some order on how the encrypted devices are opened, as this order is critical to produce a single possible PCR15 value. If we have one single device the order of measurements is not relevant, but if when have three (rootfs, /home, and swap, for example) we can have six possible and valid different values for PCR15.

The last step is that the dracut-pcr-signature service in the initrd will import from the ESP the prediction, the signature and the public key, so measure-pcr-validator can check the signature and compare the PCR value.

And that is all!

This approach is also kind of similar to what the new systemd-validatefs is doing, but for a file system level.

Protecting against rogue devices in openSUSE with Full Disk Encryption

openSUSE have now multiple ways to configure a Full Disk Encryption (FDE) installation. A very secure and easy way (YaST2) of doing this is via user space tools, as we described multiple times (like here, here, or here). This solution is based on the systemd tool-set like systemd-cryptenroll, systemd-pcrlock and systemd-cryptsetup, among other, orchestrated by the in-house sdbootutil script.

One of the main advantages of using this systemd approach is the possibility of integrating multiple authentication methods. Together with the traditional password, asked at boot time during the initrd stage, we can now unlock the system using a certificate, a TPM2, or a FIDO2 key. We can mix some of them creating multiple LUKS2 key slots, and use, for example, a TPM2 to unlock the device in a unattended fashion and a FIDO2 key as a recovery mechanism.

Honestly, the TPM2, and the TPM2+PIN variation, are the most relevant ones for the user. As described in the other posts, the TPM2 is a (some times virtual) device that can attest the health of our system using a mechanism known as measured boot.

The tl; dr version of this is that each stage of the boot process, starting from the firmware, will load and “measure” the next stage before delegating the execution on it. For example, this means that there is a moment in the latest stages of the boot process where the UEFI firmware will load from the disk the boot loader into memory. This can be the shim, systemd-boot or grub2-bls. It will calculate a hash value (usually SHA256) and will command to the TPM2 an “extend” operation for one of the internal register (PCR).

The extension is a cryptographic computation that is very easy to calculate, but impossible to replicate. It is done to one of those internal registers (PCR) and consist of calculating the hash (again SHA256) of the old value of the PCR together with the hash of the component that we are measuring. This new value will replace the current PCR value, as is the only way to change those registers. The security property resides in that it is cryptographically impossible to force the write of a desired value on one of those PCRs, but very easy to calculate the final value.

So this means that if all the components of the boot chain process are measured (all the stages in the UEFI firmware, the firmware configuration, the boot loader, the command line, the kernel and even the initrd), the final PCRs values can be compared with our expectations, and discover if the system has been booted with a good known software and configuration, allowing us to instantly known if some component in the boot chain has been hacked or modified with out consent.

That is a powerful property to have, but what is more interesting is that we can have secrets that can only be open in case that we are in one of those good or recognized states. We can, for example, cipher (seal) the key that open an encrypted disk using the TPM2, together with a policy that will decipher (unseal) the same key only, and only if we are using the same TPM2 and the PCR values are on a list of expected ones. Those policies can be very complicated, and can include extra passwords, certificates or other checks that will be validated before the TPM2 can unseal the key.

With a mechanism like this in place, thanks to the systemd tools, we can now avoid entering the password to unlock the encrypted disk if the system is in a healthy state. Healthy in the sense that we cryptographically guarantee that the code and configurations used during the boot process are the expected one, and no one entered init=/bin/bash in our kernel command line, or replaced the kernel or initrd with a vulnerable one, for example.

With the integration that we made of this model in openSUSE, we can make updates of the system, including the boot loader or the kernel, and sdbootutil will transparently generate new predictions of expected PCR values that are now considered safe. This imply an update of the TPM2 policy, that will be taken into consideration for the next boot, so the automatic unlock will succeed. If something goes wrong and the expected PCR values are not meet, the user will need to enter the password that is stored in a different LUKS2 key slot to open the device, to audit the system and validate it.

The fault in the design

Using a TPM2 as described before is a clear increase in the security level, but it is not the final answer. Security is always asymptotic approximation.

Some years ago a physical attack was described for the Windows BitLocker FDE solution. BitLocker is also using the TPM2 in a similar way that was described before, but was not using encrypted session to communicate with the device. Intercepting the SPI bus was shown possible to recover the password that unlock the disk. systemd learned from that and used encrypted sessions early, but this attack can also be avoided if the policy used to unseal the key was also demanding a PIN or password that must be entered by the user. Now the TPM2 can only unseal the secret if the PCRs are in the correct state and the provided password is the correct one. Should be noted that AFAIK the SPI sniffing can work with Clevis.

But more recently a second attack was made public that fully affect the original proposal, and does not requires the sophistication of the original one. (Disclosure: the attack was also internally described independently months before and some counter measurements was put in place much early)

The article describes how that attack can be done checking in the initrd the filesystem UUID used to mount the encrypted device. This information is inside the /etc/crypttab stored in the initrd, that will do something like this:

systemd-cryptsetup attach cr_root /dev/disk/by-uuid/$UUID ‘none’ ‘tpm2-device=auto’

If the expected firmware, configuration files, kernel and initrd are used during the boot process then the TPM2’s PCRs registers will have values that match the policy that unlock the device and the sealed key can be now unsealed by the TPM2, the disk will be unlocked, the switch root will succeed and the boot process will continue in the rootfs.

But what if the original drive is replaced by one that has the same UUID (it is a public information after all) that is also encrypted? Then the PCRs will be in the same correct state. Note that in measure boot is the previous stage the one that measures the next one before delegating the execution. Then systemd-cryptsetup will try to use the TPM2 to unlock the device using the key successfully unsealed by the TPM2 and … will fail to open it, of course. The rogue device maybe have a TPM2 key slot in the LUKS2 header, but for sure cannot be open with this TPM2 nor with the secret password.

In this situation systemd-cryptsetup will ask for the password to unlock the device, and the attacker can enter one that this time will open the rogue device. The switch root will happen but now it will continue the boot process in the fake rootfs, and a program stored there can make questions to the TPM2, that still contains the good PCR values. One of the questions can be the unseal of the secret key using the current policy. And this time (as was done before), the TPM2 will agree to deliver the secret to the bad program. Game over.

There are solutions for this attack, of course.

One is again to use TPM2+PIN instead of TPM2, the same solution for the sniffing attack. In this case the first systemd-cryptsetup call will fail and a password will be asked to unlock the device. But now the bad program cannot ask to the TPM2 to unseal the device using the current policy. The PCR values will match, but the policy also requires the enter of a secret PIN or password known by the real user, and without it the unseal will fail and the key will be keep safe.

Another solution is somehow invalidate the policy, extending some of the PCRs involved before the switch root, so the policy cannot be applied anymore after that. This can be done automatically by systemd-cryptsetup using the measure-pcr=yes in /etc/crypttab. With this option PCR15 will be extended using the volume key, a secret that can only be extracted knowing some of the device keys. For this solution to work, PCR15 needs to be included in the current policy, with an expected value of 0x000..00, the default one. Once the rogue device is open by the hacker provided password, PCR15 will be automatically extended and the value will be different from 0x000..00, invalidating the policy before the switch root.

That is a good solution, but not for us. In the daily situation the user will need to update the system, and a new policy needs to be calculated to replace the old one (for example when the kernel is updated). Because with systemd-pcrlock the policy is stored in the TPM2 in one of the Non Volatile RAM slots (NVIndex), we need to protect it somehow, so it cannot be replaced by other process. For that systemd is storing a secret key (recovery PIN) in a different NVIndex that is sealed by the same policy! If the key cannot be automatically recovered, because the policy does not apply anymore, then the recovery PIN will be asked to the user, making the update process a bit unpleasant if the policy is always invalidated.

Finally, another way to address the issue is to stop the boot process if we detect that the device is not the expected one. We can think of a new service, living in initrd that is executed in the very last moment, just before the switch root, that can stop the boot process (maybe halting the system) if the device that stores the rootfs is not the expected one.

For this, PCR15 is still a good solution. It contains the measurement of a secret (volume key) that can only be known by the real user, and cannot be replicated by the attacker. Ideally we can create a prediction for PCR15 and make this service to compare the effective value with the expected one, and if they are different then it can stop the boot process.

This is what the measure-pcr-validator service from sdbootutil is doing. sdbootutil first generates a prediction for all the encrypted devices that are opened during the initrd, and check that the correct tag is present in /etc/crypttab. To be able to access the volume key, the tool needs the root password, so this prediction is only update when it is really necessary, like for example when a new encrypted device is added. This prediction is signed by a private key stored in the host, as an extra security measurement, but because the public key is also stored in the ESP it is honestly not adding too much.

An extra service (measure-pcr-generator) will put some order on how the encrypted devices are opened, as this order is critical to produce a single possible PCR15 value. If we have one single device the order of measurements is not relevant, but if when have three (rootfs, /home, and swap, for example) we can have six possible and valid different values for PCR15.

The last step is that the dracut-pcr-signature service in the initrd will import from the ESP the prediction, the signature and the public key, so measure-pcr-validator can check the signature and compare the PCR value.

And that is all!

This approach is also kind of similar to what the new systemd-validatefs is doing, but for a file system level.

El pasado 17 de junio fue lanzado Plasma 6.4, que en palabras de sus desarrolladores, nos ofrece un escritorio más fluido, amigable y útil. Lo anuncié conveniente en el blog pero solo fue un anticipo de lo que nos ofrecía. Es el momento de profundizar en sus novedades como las mejoras en las capturas y grabación de la pantalla en Plasma 6.4, un gran impulso a una herramienta que se está convirtiendo en algo imprescindible para cualquier creador de contenido.

Mejoras en las capturas y grabación de la pantalla en Plasma 6.4

Spectacle está siguiendo la estela de Dolphin en relación con su antecesor y está obteniendo la etiqueta de mejor aplicación para capturar pantallas de cualquier sistema operativo a pesar de que deriva de otra aplicación, KSnapShot, que casi tenía ganado ese título, como así lo ha logrado Dolphin respecto a Konqueror.

De esta forma, en Plasma 6.4 Spectacle, tiene un aspecto muy distinto en Plasma 6.4 (para mejor) ya que se centrar en lo que es: un capturador y registrador del escritorio.

Así que ahoraal pulsar la tecla ImprPant para abrir Spectacle directamente en el modo de captura de pantalla: arrastra un cuadro para seleccionar una zona de la pantalla, o bien pulse Intro inmediatamente para que Spectacle capture una instantánea de la totalidad de la pantalla.

También puede empezar a hacer anotaciones de inmediato, dibujando flechas, difuminando secciones o añadiendo texto explicativo, entre otras cosas.

Por último, la calidad se ha mejorado de forma impresionante en las grabaciones de la pantalla que usan el formato WebM y en las capturas de pantallas que usan un escalado fraccionario.

Más información: KDE

Las novedades de Plasma 6.4

El entorno de trabajo ya está disponible en muchas distribuciones, así que es un buen momento para describir telegráficamente comento algunas de sus novedades:

• Mejoras en el widget Bluetooth: Identifica más tipos de dispositivos y muestra nombres reales durante el emparejamiento.
• Coherencia visual: Los widgets de Diccionario y Navegador Web ahora usan iconos simbólicos para un aspecto más uniforme.
• Navegación mejorada por teclado: Optimización de la navegación y selección mediante teclado en menús y widgets.
• Modernización de KMenuEdit: Interfaz renovada y simplificada para editar el menú de aplicaciones.
• Mejoras en accesibilidad: El widget Calculadora anuncia resultados a lectores de pantalla y se mejora la navegación accesible.
• Gestión avanzada de paneles y monitores: Mejoras en la disposición y comportamiento de pantallas y paneles.
• Mejoras de rendimiento: Optimización de la suavidad del cursor y reducción del uso innecesario de CPU en el Monitor del Sistema.
• Mejoras en el widget Fifteen Puzzle: Se han realizado ajustes funcionales y visuales en este widget de juego clásico, ofreciendo una experiencia más fluida y atractiva.
• Actualización de Discover: El centro de software ahora muestra información más clara sobre el estado de las actualizaciones y mejora la gestión de aplicaciones Flatpak y Snap.
• Nuevas opciones en la configuración del sistema: Se han añadido controles más detallados para la personalización de temas y efectos visuales, facilitando la adaptación del entorno a las preferencias del usuario.
• Notificaciones mejoradas: El sistema de notificaciones es ahora más fiable y permite una mejor gestión de mensajes persistentes y temporales.
• Soporte ampliado para pantallas táctiles: Plasma 6.4 mejora la respuesta y precisión en dispositivos con pantalla táctil, optimizando gestos y controles táctiles.
• Optimización de Wayland: Se han corregido errores y mejorado la estabilidad y el rendimiento bajo el servidor gráfico Wayland, acercándolo a la paridad con X11.
• Mejoras en la gestión de energía: Nuevas opciones y mayor eficiencia en la gestión del consumo energético, especialmente en portátiles, para prolongar la autonomía y reducir el uso de recursos.

La entrada Mejoras en las capturas y grabación de la pantalla en Plasma 6.4 se publicó primero en KDE Blog.

Los usuarios de AntennaPod no podemos acceder a los podcats públicos de la emisora pública para escuchar los podcasts de RTVE

AntennaPod es la aplicación de software libre que utilizo en mi dispositivo Android para la gestión de los podcats que escucho y a los que estoy suscrito. Ofrece una interfaz cómoda y las funcionalidades que necesito para escuchar mis podcats.

Pero desde hace un tiempo, algunos podcasts no los reproduce mientras que con otros sigue funcionando correctamente. Al principio creía que podría deberse a un problema con la aplicación, con la red, con mi dispositivos, etc. Pero al indagar un poco más, veo que los podcasts que no reproducen son los de RTVE y que no me ha pasado a mí solo…

Después de un tiempo de desconcierto y probar distintas cosas, veo por la red un issue en el repo de AntennaPod en GitHub que otra persona menciona ese mismo problema y que en el foro de usuarios de AntennaPod son más las personas afectadas que comentan los mismos problemas.

Parece ser que RTVE, la televisión y radio públicas del estado español, ha bloqueado el user agent de AntennaPod a la hora de acceder a su contenido. Contenido de un medio público que ofrece de manera libre y gratuita desde su web u otros medios de escucha.

Desde la línea de comandos se puede comprobar ese bloqueo al user agent de AntennaPod mediante curl.

Así el contenido no se descarga:

curl -L -A "AntennaPod/3.1.0" "https://ztnr.rtve.es/ztnr/16647613.mp3" > descarga.mp3

Así sí se descarga sin problemas:

curl -L -A "firefox" "https://ztnr.rtve.es/ztnr/16647613.mp3" > descarga.mp3

De esta manera RTVE está en contra de la neutralidad de la red, algo que en un medio estatal y público es bastante lamentable.

Hay usuarios de AntennaPod que han enviado una queja a la defesora del oyente de RTVE y la contestación más o menos fue que: RTVE desea que los accesos a sus contenidos se hagan desde las aplicaciones oficiales, para así tener una contabilidad del material más escuchado, y todo para mejorar el servicio, por supuesto.

Una respuesta un poco sin sentido, porque en mi portátil y desde mi reproductor multimedia, Amarok en mi caso, también estoy suscrito a algunos podcasts de RTVE y puedo acceder sin problemas, o directamente descargarlos desde la línea de comandos, etc…

Para que cuente, yo también he enviado mi queja a la defensora del oyente así como a algún programa de radio que sigo en podcasts (aunque ha sido bastante difícil encontrar un medio de contacto válido que no sean redes asociales privativas).

En definitiva una medida que deja fuera de acceso a contenido público de RTVE a muchas personas que utilizamos AntennaPod.

Podría asemejarse al hecho de que para ver su contenido en la televisión o escuchar su radio, solo fuera posible con determinado modelo de televisión o una marca específica de radio. Espero que desde RTVE cambien esa arbitrariedad a la hora de escuchar su contenido.

Enlaces de interés

• https://antennapod.org/es/
• https://github.com/AntennaPod/AntennaPod/issues/7864
• https://forum.antennapod.org/t/rne-podcasts-not-working/6849

El pasado 17 de junio fue lanzado Plasma 6.4, que en palabras de sus desarrolladores, nos ofrece un escritorio más fluido, amigable y útil. Lo anuncié conveniente en el blog pero solo fue un anticipo de lo que nos ofrecía. Es el momento de profundizar en sus novedades como las mejoras de Krunner en Plasma 6.4, que no son muchas porque en realidad ¿qué creéis que le falta?

Mejoras de Krunner en Plasma 6.4, ahora gestiona colores

Si hay una aplicación que merezca el sobrenombre de «navaja suiza» en el entorno de trabajo Plasma de la Comunidad KDE esta podría ser Krunner (y digo podría, porque las funcionalidades de Dolphin también son extraordinarias). Este «lanzador de aplicaciones» hace de todo y, aunque parezca mentira, mejora versión a versión.

De hecho, para esta entrada he realizado una pequeña lista de 9 cosas que puede hacer Krunner:

De esta forma, Plasma 6.4 ofrece una nueva e interesante funcionalidad: nos permite gestionar mejor los colores a la hora de seleccionar el color exacto que queremos.

Solo tenemos introducir el color en notación hexadecimal, como un número hexadecimal, o su nombre CSS/SVG (como «MintCream», «PeachPuff» o «PapayaWhip», que son nombres de colores y no postres sofisticados) para que KRunner muestre el aspecto de dicho color y su nombre o código equivalente en otras notaciones.

Un complemente ideal al widget «Selector de colores» de Plasma.

Más información: KDE

Las novedades de Plasma 6.4

El entorno de trabajo ya está disponible en muchas distribuciones, así que es un buen momento para describir telegráficamente comento algunas de sus novedades:

• Mejoras en el widget Bluetooth: Identifica más tipos de dispositivos y muestra nombres reales durante el emparejamiento.
• Coherencia visual: Los widgets de Diccionario y Navegador Web ahora usan iconos simbólicos para un aspecto más uniforme.
• Navegación mejorada por teclado: Optimización de la navegación y selección mediante teclado en menús y widgets.
• Modernización de KMenuEdit: Interfaz renovada y simplificada para editar el menú de aplicaciones.
• Mejoras en accesibilidad: El widget Calculadora anuncia resultados a lectores de pantalla y se mejora la navegación accesible.
• Gestión avanzada de paneles y monitores: Mejoras en la disposición y comportamiento de pantallas y paneles.
• Mejoras de rendimiento: Optimización de la suavidad del cursor y reducción del uso innecesario de CPU en el Monitor del Sistema.
• Mejoras en el widget Fifteen Puzzle: Se han realizado ajustes funcionales y visuales en este widget de juego clásico, ofreciendo una experiencia más fluida y atractiva.
• Actualización de Discover: El centro de software ahora muestra información más clara sobre el estado de las actualizaciones y mejora la gestión de aplicaciones Flatpak y Snap.
• Nuevas opciones en la configuración del sistema: Se han añadido controles más detallados para la personalización de temas y efectos visuales, facilitando la adaptación del entorno a las preferencias del usuario.
• Notificaciones mejoradas: El sistema de notificaciones es ahora más fiable y permite una mejor gestión de mensajes persistentes y temporales.
• Soporte ampliado para pantallas táctiles: Plasma 6.4 mejora la respuesta y precisión en dispositivos con pantalla táctil, optimizando gestos y controles táctiles.
• Optimización de Wayland: Se han corregido errores y mejorado la estabilidad y el rendimiento bajo el servidor gráfico Wayland, acercándolo a la paridad con X11.
• Mejoras en la gestión de energía: Nuevas opciones y mayor eficiencia en la gestión del consumo energético, especialmente en portátiles, para prolongar la autonomía y reducir el uso de recursos.

La entrada Mejoras de Krunner en Plasma 6.4, ahora gestiona colores se publicó primero en KDE Blog.