Java 25 y la seguridad

Java 25 (septiembre de 2025) es la versión LTS (Long-Term Support) actual y la que usa esta guía. Spring Boot 4 funciona desde Java 17, pero si empiezas un proyecto hoy, Java 25 es la elección natural: soporte largo y varias novedades que tocan directamente la seguridad. Esta lección recorre las que más importan, incluidas las que llegaron en Java 22–24 y quedan consolidadas en esta LTS.

Novedad	JEP	Desde	Para qué te sirve
Scoped Values	506	25 (final)	Compartir datos de la petición (usuario, tenant) de forma inmutable y segura con hilos virtuales
API de derivación de claves (KDF)	510	25 (final)	Derivar claves con HKDF sin librerías externas
ML-KEM y ML-DSA	496, 497	24	Intercambio de claves y firmas resistentes a ordenadores cuánticos
Hilos virtuales sin pinning en synchronized	491	24	synchronized ya no bloquea el hilo portador
Security Manager desactivado para siempre	486	24	Ya no es una frontera de seguridad: aísla con el sistema operativo o contenedores
Ficheros fuente compactos y main de instancia	512	25 (final)	Programas de prueba de una sola clase, sin public static ni imports del java.base
Codificación PEM	470	25 (preview)	Leer y escribir claves y certificados PEM con la API estándar

Scoped Values: contexto seguro con hilos virtuales

Analogía

La pulsera del evento frente a la taquilla

Con un casillero, si olvidas vaciarlo, el siguiente que lo use encuentra tus cosas. Con la pulsera eso no puede pasar: deja de existir cuando sales del recinto.

En el mundo realEn tu sistema

Un casillero por persona donde cualquiera puede cambiar lo que hay dentroThreadLocal: mutable, ligado al hilo, hay que limpiarlo

Una pulsera que te ponen al entrar y te quitan al salirScopedValue: inmutable, válido solo dentro de un bloque

Tus acompañantes llevan la misma pulseraLas tareas hijas (*structured concurrency*) heredan el valor

Un ThreadLocal tiene tres problemas de seguridad: es mutable (cualquier código puede cambiarlo), hay que limpiarlo a mano (si no, el siguiente uso del hilo hereda la identidad del anterior) y su vida no está acotada. Un ScopedValue es inmutable y solo existe dentro del bloque donde se asigna:

Evita

static final ThreadLocal<String> TENANT = new ThreadLocal<>();

void handle(Request req) {
    TENANT.set(req.tenant());
    try {
        process(req);
    } finally {
        TENANT.remove();   // si se olvida, fuga entre peticiones
    }
}

Prefiere

static final ScopedValue<String> TENANT = ScopedValue.newInstance();

void handle(Request req) {
    ScopedValue.where(TENANT, req.tenant())
        .run(() -> process(req));   // fuera del bloque, TENANT no existe
}

void process(Request req) {
    String tenant = TENANT.get();   // inmutable: nadie puede cambiarlo aquí
}

Idea clave

Spring Security 7 sigue guardando el SecurityContext en un ThreadLocal (el SecurityContextHolder), y funciona bien con hilos virtuales: cada petición tiene su propio hilo. Usa ScopedValue para tus datos de contexto (tenant, id de correlación, permisos calculados) en lugar de añadir más ThreadLocal.

Desde Java 24, además, un hilo virtual dentro de un bloque synchronized ya no queda “anclado” a su hilo portador (JEP 491). Código como el TokenBucket de la lección de abuso de APIs ya no penaliza el rendimiento con hilos virtuales.

Derivar claves con la API KDF

Muchas veces tienes un secreto maestro y necesitas varias claves (una para cifrar, otra para firmar, una por tenant). Usar el mismo secreto para todo es un error clásico; la solución estándar es una función de derivación de claves como HKDF. Desde Java 25 viene en el JDK:

1. Secreto maestrode un KMS o un intercambio de claves
2. extract + sal
3. HKDF-SHA256KDF.getInstance(…)
4. expand + info
5. Claves independientesAES para cifrarHMAC para firmar

Cambiar el parámetro info produce claves distintas e independientes a partir del mismo secreto.

KeyDerivation.java

SecretKey deriveKey(byte[] masterSecret, byte[] salt, String purpose) throws GeneralSecurityException {
    KDF hkdf = KDF.getInstance("HKDF-SHA256");
    AlgorithmParameterSpec params = HKDFParameterSpec.ofExtract()
        .addIKM(masterSecret)
        .addSalt(salt)
        .thenExpand(purpose.getBytes(StandardCharsets.UTF_8), 32);   // 32 bytes = 256 bits
    return hkdf.deriveKey("AES", params);
}

SecretKey encryptionKey = deriveKey(master, salt, "notes:encryption:v1");
SecretKey signingKey    = deriveKey(master, salt, "notes:signing:v1");

Trampa común

HKDF no es para contraseñas

HKDF es rápido a propósito: sirve para derivar claves a partir de secretos que ya son aleatorios y largos. Para contraseñas de usuarios sigues necesitando un hash lento como Argon2id o bcrypt (repasa contraseñas y hashing).

Criptografía post-cuántica

Un ordenador cuántico suficientemente grande rompería RSA y las curvas elípticas. El riesgo de hoy es “cosechar ahora, descifrar después”: alguien guarda tráfico cifrado actual para descifrarlo dentro de unos años. Java 24 incorporó los algoritmos estandarizados por el NIST:

• ML-KEM (FIPS 203): encapsulación de claves, para acordar secretos (sustituto de ECDH).
• ML-DSA (FIPS 204): firmas digitales (sustituto de RSA/ECDSA para firmar).

PostQuantum.java

KeyPair pair = KeyPairGenerator.getInstance("ML-DSA").generateKeyPair();   // ML-DSA-65 por defecto

Signature signer = Signature.getInstance("ML-DSA");
signer.initSign(pair.getPrivate());
signer.update(document);
byte[] signature = signer.sign();

La API es la misma que ya conoces de la lección de criptografía: solo cambia el nombre del algoritmo. Los JWT con firmas post-cuánticas aún no son habituales en los proveedores de identidad, pero conviene saber que el JDK ya está preparado.

PEM sin librerías (preview)

Las claves y certificados suelen venir en formato PEM (-----BEGIN PUBLIC KEY-----). Java 25 incluye, como preview, PEMEncoder y PEMDecoder para leerlos y escribirlos sin Bouncy Castle ni código manual de Base64:

Pem.java

String pem = PEMEncoder.of().encodeToString(publicKey);
PublicKey key = PEMDecoder.of().decode(pem, PublicKey.class);

Al ser preview, necesitas --enable-preview y la API puede cambiar en la siguiente versión. En Spring Boot, para claves de firma de JWT, sigue siendo más cómodo public-key-location o @ConfigurationProperties con RSAPublicKey (como en la lección de JWT).

El Security Manager ya no existe

Durante 25 años, Java tuvo un Security Manager pensado para ejecutar código no confiable en una “caja de arena”. Desde Java 24 está desactivado de forma permanente (JEP 486): no se puede activar.

• Si tu aplicación lo usaba para limitar plugins o scripts, ya no protege nada.
• El aislamiento hoy se hace fuera de la JVM: contenedores, usuarios sin privilegios, sistemas de ficheros de solo lectura, seccomp, políticas de red.
• Y la regla de siempre: no ejecutes código ni expresiones que vengan del usuario (SpEL, scripts, plantillas) sin una lista blanca muy estricta.

Ficheros fuente compactos para experimentar

Para probar una idea de seguridad en un minuto ya no hace falta un proyecto: en Java 25 un fichero con un main de instancia importa automáticamente todo el módulo java.base y se ejecuta con java Fichero.java. El cálculo de PKCE de la lección de OAuth 2 queda así:

Pkce.java

void main() throws Exception {
    byte[] random = new byte[32];
    new SecureRandom().nextBytes(random);
    String verifier = Base64.getUrlEncoder().withoutPadding().encodeToString(random);

    byte[] hash = MessageDigest.getInstance("SHA-256").digest(verifier.getBytes(StandardCharsets.US_ASCII));
    IO.println("verifier  = " + verifier);
    IO.println("challenge = " + Base64.getUrlEncoder().withoutPadding().encodeToString(hash));
}

java Pkce.java

Mini lab · 20 min

Contexto y claves con Java 25

Marcar como completado

Objetivo: Practicar Scoped Values y derivación de claves, y razonar sobre lo que cambió en la plataforma.

Con un JDK 25 instalado (java -version):

1. Escribe un fichero compacto que derive con HKDF dos claves desde el mismo secreto de 32 bytes aleatorios, una con info = "notes:encryption:v1" y otra con "notes:signing:v1", e imprime ambas en Base64. Ejecútalo dos veces con el mismo secreto y la misma sal.
2. Declara un ScopedValue<String> USER y, dentro de ScopedValue.where(USER, "ana").run(...), llama a un método que lea USER.get(). Después intenta leerlo fuera del bloque.
3. Responde: un compañero propone “como ya no hay Security Manager, ejecutamos los scripts de los usuarios en la misma JVM con un ClassLoader aparte”. ¿Qué le dices?

Pista

Para el paso 2, busca qué excepción lanza get() cuando el valor no está asignado, y qué método te permite comprobarlo antes.

Mostrar respuestaOcultar respuesta

1. Las dos claves son distintas entre sí (cambia info) pero idénticas entre ejecuciones con el mismo secreto y sal: HKDF es determinista. Por eso puedes recalcular las claves cuando las necesites sin guardarlas, y versionarlas cambiando info (…:v2).
2. Dentro del bloque, USER.get() devuelve "ana". Fuera, lanza NoSuchElementException: el valor solo existe durante la ejecución del bloque. Puedes comprobarlo con USER.isBound(). No hay nada que limpiar ni posibilidad de que la siguiente petición herede “ana”.
3. Que un ClassLoader no es una frontera de seguridad: el script tendría los mismos permisos que la aplicación (ficheros, red, variables de entorno con secretos). Sin Security Manager, el aislamiento tiene que hacerse fuera de la JVM: un proceso o contenedor separado, sin credenciales, con red y sistema de ficheros restringidos, límites de CPU y memoria, o directamente un motor de reglas con un lenguaje acotado en lugar de código arbitrario.

En resumen

• Java 25 es la LTS actual y la versión recomendada para Spring Boot 4 (mínimo 17).
• ScopedValue sustituye a ThreadLocal para tus datos de contexto: inmutable y acotado; Spring Security sigue usando su SecurityContextHolder.
• KDF con HKDF deriva claves independientes desde un secreto; nunca para contraseñas.
• ML-KEM y ML-DSA llevan la criptografía post-cuántica al JDK; PEM llega como preview.
• Sin Security Manager, el aislamiento de código no confiable se hace fuera de la JVM.