Cuando la configuración del servicio lo permite, cada token dentro dicho servicio cuenta con un secreto de autenticación adicional que le permite informar al servidor sobre cualquier situación donde el usuario se considere bajo coacción. Un ejemplo común sería que un criminal forzara al usuario a abrir su token para ejecutar algún tipo de transacción.
Una aplicación que quiera implementar esta funcionalidad debe tener tanto un mecanismo para poder registrar un secreto de coacción con el servidor y luego seleccionar el secreto apropiado dependiendo de la interacción del usuario.
Hay ciertos casos de uso (por ejemplo, si la aplicación decide utilizar la autenticación biométrica disponible en el smartphone) donde esto puede muy difícil o directamente imposible de implementar, pero como se menciona más abajo, no es necesario ni razonable implementar la funcionalidad de coacción en todos los casos.
El próximo punto analiza la seguridad de esta función de la forma que está implementada en ZofToken Universal App, lo cual también sería válido para cualquier otra aplicación que implemente ZofToken SDK y las funciones de protección de secretos disponibles en el mismo a través de la elección de un PIN normal y un PIN de coacción.
En ZofToken Universal App, usar la función de coacción es totalmente transparente desde la perspectiva de la aplicación dado que ninguno de los dos PIN se guardan en el smartphone y el tráfico de red en este caso es indistinguible de la apertura normal de un token.
Aún si un atacante, independientemente de su capacidad técnica, tuviera acceso completo a todos los datos en el smartphone y todo el tráfico entre la aplicación y el servidor, no le sería posible determinar si se está utilizando un PIN de coacción o inclusive si existe un PIN de coacción configurado por el usuario o no.
El servidor, sin embargo, identifica la acción en el token como realizada bajo coacción, la registra en una bitácora, establece el estado apropiado para el token y, en el caso de estar configurado, dispara un webhook indicando esta situación y eventualmente generando la alarma correspondiente.
No existen argumentos técnicos en contra de su activación dado que no introduce complejidades adicionales y podría utilizarse en cualquier tipo de integración. No obstante lo anterior, una vez habilitada, tanto los sistemas integrados a ZofToken como los procedimientos operativos vinculados a los mismos deben estar prontos para lidiar con una situación de coacción de alguna forma que haga sentido tanto para la organización como para el usuario del token.
Para entender alguna de las implicancias, se puede analizar lo que sería un ejemplo clásico: un usuario está intentando mover fondos hacia una cuenta externa en un sistema de Home Banking y cuando el sistema revisa el estado del token, encuentra que el usuario lo abrió indicando que está bajo coacción.
En este momento, el sistema tiene una serie de opciones, algunas de las cuales incluyen (considerando potenciales ventajas y desventajas):
Existen muchas otras opciones o variantes de las presentadas, pero lo que es claro es que no resulta simple la decisión de habilitar la función de coacción (que implica que los usuarios deben poder confiar en la misma) o no. Cuanto más limitado sea el grupo de usuarios involucrados (por ejemplo, el personal interno de IT o un grupo selecto de clientes considerados premium) posiblemente resulte más sencillo definir un procedimiento apropiado para manejar este tipo de eventos, mientras que habilitarlo para grupos grandes y sin mayores controles probablemente sea inapropiado.
ZofToken provee esta función dado que la misma puede ser extremadamente importante en ciertas industrias o ambientes de alta seguridad y además puede ser un mecanismo para que una organización le agregue un valor significativo a ciertos grupos de usuarios o clientes importantes. En cualquier caso, recomendamos que la organización haga un análisis apropiado donde se comparen con cuidado las oportunidades y riesgos involucrados.
