PowerBuilder
PowerBuilder 2025 R2 AES-GCM: cifrado autenticado nativo y detección de manipulación
0 visualizaciones
Un artículo técnico sobre la nueva funcionalidad criptográfica de PowerBuilder 2025 R2 usando CrypterObject, CoderObject, AES-256-GCM, payload hexadecimal y validación mediante Auth Tag.
Detalles
Introducción
PowerBuilder 2025 R2 incorpora una mejora muy importante para aplicaciones empresariales: soporte nativo para operaciones criptográficas modernas mediante CrypterObject y CoderObject. Este proyecto demo se concentra en una de las capacidades más relevantes para sistemas reales: cifrado autenticado AES-GCM.
AES-GCM no es solamente cifrado. Es cifrado autenticado. Esto significa que el receptor puede detectar si el payload cifrado fue alterado después de salir del emisor. Para archivos de pago, documentos fiscales, mensajes ERP, payloads de API, instrucciones bancarias y cualquier intercambio JSON sensible, esto cambia el modelo de seguridad: confidencialidad e integridad se resuelven en una misma operación.
Este artículo usa el proyecto Demo_AES-GCM_pb, implementado en la ventana w_demo_security.srw. El usuario cifra un JSON fiscal, lo transmite como texto hexadecimal, simula la recepción y luego modifica intencionalmente un carácter para comprobar que la manipulación es rechazada.
Por qué AES-GCM es importante
Los enfoques simétricos tradicionales suelen depender de AES-CBC o AES-ECB más un proceso HMAC separado. Ese modelo funciona solo si cada detalle está bien implementado: manejo del IV, padding, cálculo del MAC, verificación del MAC y comportamiento ante errores. AES-GCM simplifica el diseño porque produce una etiqueta de autenticación como parte del cifrado.
Ventaja del nuevo método en PowerBuilder 2025 R2
1. Análisis retrospectivo: el enfoque vulnerable en versiones anteriores
Históricamente, el cifrado simétrico en entornos PowerBuilder se implementaba con algoritmos como AES en modo CBC (Cipher Block Chaining) o ECB (Electronic Codebook), normalmente a través de funciones estándar de CrypterObject. Aunque este enfoque ofrecía confidencialidad básica, dejaba expuestas vulnerabilidades críticas conocidas por la industria.
• Maleabilidad del texto cifrado (bit-flipping): en modo CBC, un atacante con acceso al flujo de datos puede alterar bits específicos del bloque cifrado. Al descifrarse en destino, esa alteración puede modificar de forma predecible el texto plano resultante, por ejemplo cambiando un dígito de un monto, sin que el algoritmo por sí solo detecte que el mensaje fue manipulado.
• Ataques de oráculo de relleno (Padding Oracle Attacks): los modos antiguos trabajan con bloques de tamaño fijo y requieren padding, como PKCS#7. Si el receptor expone errores diferenciados entre relleno inválido, llave incorrecta u otros fallos, un atacante puede enviar variaciones del mensaje y usar esas respuestas como oráculo para recuperar información sensible.
2. La solución moderna: cifrado autenticado AEAD
PowerBuilder 2025 R2 mitiga estos riesgos al incorporar soporte nativo para AES-GCM (Galois/Counter Mode) y algoritmos modernos como RSA-PSS para firma asimétrica. AES-GCM pertenece a la familia AEAD: Authenticated Encryption with Associated Data. Esto significa que el cifrado no solo protege la confidencialidad del mensaje, sino que también genera una etiqueta de autenticación, o Auth Tag, que permite comprobar su integridad.
Si un solo bit del ciphertext, del Auth Tag o de los datos protegidos se altera, la validación deja de coincidir y el receptor debe rechazar el payload. En términos prácticos, AES-GCM combina confidencialidad e integridad en una sola operación criptográfica, reduciendo la necesidad de construir manualmente una capa HMAC separada.
3. Cuadro comparativo de arquitectura segura
Arquitectura del demo
El demo es intencionalmente compacto. Mantiene todo el flujo de seguridad dentro de una ventana PowerBuilder para que el desarrollador vea cada transición: JSON plano, payload cifrado y JSON recuperado.
Estado inicial: el JSON es editable, el canal cifrado está vacío y el panel receptor espera un payload válido.
Los tres paneles representan un intercambio realista entre sistemas:
• JSON Original: mensaje de negocio creado por el emisor. El ejemplo usa un documento fiscal y bancario.
• Payload Cifrado (Hex): canal de transporte. Contiene data_encriptada_hex, auth_tag_hex y el nombre del algoritmo.
• JSON Descifrado: salida del receptor después del descifrado autenticado.
Flujo de la “Prueba de Fuego”
La parte más importante del demo es la prueba de manipulación. El usuario cambia un solo carácter hexadecimal en el payload cifrado y ejecuta nuevamente el receptor. Esto simula un mensaje corrupto, una integración defectuosa o una modificación por un atacante en tránsito.
Flujo técnico de la prueba de fuego: cifrado del emisor, canal hexadecimal, descifrado del receptor, ruta válida del Auth Tag y ruta de rechazo cuando el payload fue alterado.
Paso 1: cargar el JSON de negocio
Al abrir la ventana, el demo carga un payload JSON en el panel izquierdo. El texto incluye datos fiscales, emisor, receptor, impuestos, datos bancarios y método de pago. Esto es importante porque un demo criptográfico resulta más útil cuando el payload se parece a datos de negocio reales y no a una cadena de prueba demasiado simple.
1event open;2String ls_json34ls_json = '{~r~n' + &5 ' "operacion": {~r~n' + &6 ' "id_transaccion": "TXN-2026-0707-8842",~r~n' + &7 ' "fecha_registro": "2026-07-07T21:15:30Z",~r~n' + &8 ' "tipo_poliza": "Egresos",~r~n' + &9 ' "estatus": "Pendiente_Timbrado"~r~n' + &10 ' }~r~n' + &11 '}'1213mle_json_original.Text = ls_json14end event
En el evento de cifrado, el texto se convierte explícitamente a un blob UTF-8:
1lb_plain_data = Blob(ls_json_input, EncodingUTF8!)
Este detalle es crítico para aplicaciones empresariales en español. Nombres, descripciones, conceptos fiscales y direcciones pueden contener acentos y caracteres especiales. El demo usa conversión UTF-8 para evitar corrupción de caracteres durante el cifrado y el descifrado.
Paso 2: generar llave e IV
El emisor genera el material criptográfico mediante CrypterObject. En este demo, la llave y el IV se guardan como variables de instancia para simular un secreto compartido entre el Sistema A y el Sistema B durante la misma sesión de ejecución.
1li_rtn = lnv_crypt.SymmetricGenerateKey(AES!, 32, ib_secret_key)2li_rtn = lnv_crypt.SymmetricGenerateKey(AES!, 16, ib_iv)
Paso 3: cifrar con AES-GCM
La operación central es la llamada nativa de cifrado en PowerBuilder 2025 R2. El demo utiliza AES_GCM! y OperationModeCTR!, tal como está implementado en el proyecto.
1lb_encrypted = lnv_crypt.SymmetricEncrypt( &2 AES_GCM!, &3 lb_plain_data, &4 ib_secret_key, &5 OperationModeCTR!, &6 ib_iv)
El blob cifrado devuelto por la operación contiene los datos cifrados más la etiqueta de autenticación. El demo separa los últimos 16 bytes como Auth Tag y conserva el resto como ciphertext.
1lb_auth_tag = BlobMid(lb_encrypted, Len(lb_encrypted) - 15, 16)2lb_cipher_only = BlobMid(lb_encrypted, 1, Len(lb_encrypted) - 16)34ls_cipher_hex = lnv_coder.HexEncode(lb_cipher_only)5ls_tag_hex = lnv_coder.HexEncode(lb_auth_tag)
Después del cifrado, el panel central contiene el ciphertext hexadecimal y el Auth Tag de 128 bits.
Paso 4: construir el payload de transporte
El demo usa JSON como envoltorio y texto hexadecimal como formato de transporte. Esto permite inspeccionar, copiar o enviar el contenido cifrado por canales orientados a texto.
1{2 "data_encriptada_hex": "A73CCCE9A9203BC5...",3 "auth_tag_hex": "38754F6BC4B94C30EE98C64D3749B68E",4 "algoritmo": "AES-256-GCM"5}
Desde el punto de vista de integración, el contrato es claro: el Sistema A envía los bytes cifrados en hexadecimal, envía el Auth Tag por separado y declara el algoritmo. El Sistema B puede decodificar, recomponer y validar el payload.
Paso 5: recibir, decodificar y recomponer
El receptor extrae los dos valores hexadecimales del payload, los decodifica como blobs y reconstruye el payload completo que espera la operación de descifrado.
1lb_encrypted = lnv_coder.HexDecode(ls_payload_hex)2lb_auth_tag = lnv_coder.HexDecode(ls_tag_hex)34lb_full_payload = lb_encrypted + lb_auth_tag5lb_decrypted = lnv_crypt.SymmetricDecrypt( &6 AES_GCM!, &7 lb_full_payload, &8 ib_secret_key, &9 OperationModeCTR!, &10 ib_iv)
Si los datos cifrados y el Auth Tag coinciden, el receptor restaura el JSON original en UTF-8.
1ls_json_recuperado = String(lb_decrypted, EncodingUTF8!)
Recepción exitosa: el Auth Tag es aceptado y el JSON original se restaura en el panel receptor.
Paso 6: detección de manipulación
La prueba de fuego es directa: modificar un carácter en data_encriptada_hex y hacer clic otra vez en Simular Recepcion y Descifrado. Un solo carácter hexadecimal representa cuatro bits. Ese cambio mínimo es suficiente para romper la relación entre ciphertext y Auth Tag.
Payload manipulado: después de modificar un carácter hexadecimal, el receptor bloquea el mensaje y muestra una alerta de seguridad.
Detalle de implementación: validación a nivel de demo
El código del demo convierte el blob descifrado nuevamente a UTF-8 y verifica que el contenido restaurado mantenga la estructura esperada del JSON. Si el resultado está vacío o no luce como el JSON esperado, la recepción se bloquea.
1If Len(lb_decrypted) > 0 And Right(Trim(ls_json_recuperado), 1) = "}" Then2 mle_json_descifrado.Text = ls_json_recuperado3 MessageBox("Recepcion Exitosa", &4 "La firma de integridad (Auth Tag) es valida." + &5 "~r~nEl JSON ha sido descifrado correctamente.", Information!)6Else7 mle_json_descifrado.Text = "ACCESO DENEGADO - DATOS CORRUPTOS O MANIPULADOS"8 MessageBox("ALERTA DE SEGURIDAD", &9 "El descifrado fallo." + &10 "~r~n~r~nLa firma de integridad GMAC NO coincide.", StopSign!)11End If
En sistemas productivos, el mismo principio debe reforzarse con manejo estricto de errores del descifrado autenticado, validación de esquema, parseo JSON estructurado y registro de seguridad. La regla es absoluta: si la autenticación falla, la aplicación debe rechazar el payload.
Protecciones del sistema operativo
El demo también resalta el endurecimiento de plataforma. Cuando se ejecuta desde el IDE de PowerBuilder, el código corre dentro del proceso del IDE. Para ejecutables productivos, conviene revisar la sección de seguridad en el Project Painter para que la aplicación generada aproveche mitigaciones como ASLR, DEP y SafeSEH cuando correspondan.
Project Painter en PowerBuilder 2025 R2: pestaña Security con la sección Advanced Executable Security y las mitigaciones DEP, ASLR, CFG y SafeSEH seleccionadas.
La imagen muestra exactamente dónde se revisan estas opciones dentro del proyecto de despliegue. En el Project Painter, la pestaña Security incluye dos áreas relevantes: la firma del ejecutable y la sección Advanced Executable Security. Para este demo, la parte clave es la segunda, donde se pueden activar mitigaciones modernas del sistema operativo antes de generar el ejecutable.
El flujo recomendado es simple: abrir el proyecto de despliegue, entrar a Security, marcar estas opciones en Advanced Executable Security, compilar y luego verificar el ejecutable generado con herramientas como PESecurity, dumpbin, WinDbg o Process Explorer. En proyectos de 64 bits, SafeSEH puede no aparecer o no aplicar porque Windows utiliza otro mecanismo de manejo de excepciones.
Mejoras recomendadas para producción
• Usar una estrategia segura de administración de llaves en lugar de generar llaves dentro de la ventana.
• Almacenar o transmitir el IV/nonce según el protocolo y evitar reutilizaciones inseguras con la misma llave.
• Validar JSON con un parser al pasar de demo a producción, no con búsquedas de texto.
• Centralizar funciones criptográficas en un objeto no visual para mantener eventos visuales más limpios.
• Registrar fallas de autenticación sin exponer texto plano, llaves ni payloads sensibles.
• Mantener explícitas todas las conversiones de texto con EncodingUTF8!.
Conclusión
Este demo muestra por qué AES-GCM en PowerBuilder 2025 R2 es una funcionalidad nueva de alto valor. Una aplicación PowerBuilder puede cifrar payloads de negocio, codificarlos para transporte, recuperarlos como JSON UTF-8 y rechazar datos manipulados usando objetos nativos.
La “prueba de fuego” es el efecto WOW: se modifica un solo carácter del canal hexadecimal y el receptor deniega el acceso. Ese es el valor práctico del cifrado autenticado: la aplicación no solo oculta los datos, también comprueba si llegaron íntegros.