Chavel Móvel Digital (CMD) Pre-Populated Checklist

Below is a table with pre-populated answers to CMD’s checklist.

Most of the items are generic, must some may depend on your use case. In such cases with added the tag [TO BE ANSWERED BASED ON THE PROJECT SCOPE].

The check list answers are in portuguese as requested per AMA.

#	Guideline	Description	Recommended Response
1	PIN CMD por assinatura	Exigir a introdução do PIN da CMD por cada assinatura ou batch de assinatura efetuada. Não o guardando na BD ou em sessão.	Quaisquer tipo de credenciais relacionadas com CMD (tlm, pin, …) não são persistidos em qualquer tipo de repositório, e mesmo em sessão e memória encontram-se obfuscados.
2	Documento a assinar visivel	Apresentar sempre o documento a assinar pelo cidadão.	Todas as assinaturas do tipo CMD realizadas no eSign são no contexto do documento que está no momento da assinatura a ser apresentado ao utilizador.
3	Dispositivos seguros	Não permitir a instalação da aplicação em dispositivos comprometidos	*[TO BE ANSWERED BASED ON THE PROJECT SCOPE]*
4	PIN CMD não visivel	Não apresentar visivel para o utilizador os digitos do PIN da CMD	A recolha de quaisquer dados confidenciais nunca é feita a descoberto, sendo realizada com campos standard próprios para o efeito; nomeadamente campos HTML5 do tipo password. Adicionalmente, os pins e otp’s, além de cifrados via comunicação HTTPS são cifrados com a chave pública da AMA no browser, o que permite que um ataque de man-in-the-middle não tenha acesso às credenciais do utilizador a descoberto. Como layer de segurança adicional, e a fim de impedir que um pin cifrado possa ser apanhado por um ataque de man-in-the-middle e reutilizado em futuras chamadas diretas aos serviços da AMA, é ainda aplicado ao transporte entre o frontend e o backend do eSign uma cifra com uma chave de sessão única do eSign. À chegada ao backend (e imediatamente antes da integração com os serviços da AMA) a cifra de sessão do eSign é removida, sendo a cifra da AMA é mantida ponto-a-ponto. - eSign Frontend: cifra_esign_session[cifra_ama[pin]] - eSign Backend: cifra_ama[pin] - AMA: cifra_ama[pin]
5	PIN CMD não guardado localmente	Não guardar nos logs os dados do PIN ou Pin temporário	O produto eSign não guarda, em qualquer altura, logs com dados sensíveis da CMD. eSign utiliza ainda a versão mais recente da assinatua com CMD (SCMD), com o propósito de garantir que mesmo com logs de rede e infraestrutura não capturam os dados sensíveis a descoberto. Para este efeito os PINs são cifrados ainda no client-side com a chave pública da AMA chave pública de sessão e uma chave de sessão do próprio produto eSign, a fim de garantir que mesmo que estes sejam apanhados na rede (interna ou externa) não poderão ser decifrados. Guarda de evidência O eSign guarda evidência do par User+OTP, com o objectivo de, em caso de disputa legal, existirem evidencias da informação que foi introduzida pelo cliente para se poder fazer cross-check com o que chegou à AMA. De notar que credenciais reutilizáveis (pin) nunca são logadas nem persistidas de qualquer forma pelo eSign. A evidencia do User+OTP (cifrados com a chave pública da AMA) é guardada dentro do PDF assinado e nas tabelas de auditoria da aplicação. De notar que o código OTP apenas é guardado após ser consumido pelo serviço da AMA, garantindo que não pode ser reutilizado. *[TO BE ANSWERED BASED ON THE PROJECT SCOPE - JUSTIFY THAT NETWORK AND FIREWALLS WILL NOT DECODE HTTPS AND LOG THE INCOMING MESSAGES]*
6	PIN CMD não transmitido	Não transmitir para qualquer outra aplicação dados do PIN da CMD ou PIN temporário (além da aplicação da CMD)	Dados sensíveis de CMD são utilizados numa óptica de fire-and-forget, não sendo persistidos nem transmitidos a mais nenhuma entidade que não a aplicação de CMD.
7	Comprometimento aplicação	Em caso de compromentimento da aplicação informar a AMA num prazo inferior a 4 horas (após conhecimento do incidente de segurança).	*[TO BE ANSWERED BASED ON THE PROJECT SCOPE]*
8	Atualização aplicação	Detetar a existência de novas versões da aplicação e permitir a atualização automatica da aplicação	A aplicação eSign é uma web app, não existindo distribuição de binários para os utilizadores finais.
9	Credenciais autenticação aplicação	Não partilhar as credenciais de acesso a aplicação a serviço CMD assinatura com qualquer outra entidade ou aplicação	*[TO BE ANSWERED BASED ON THE PROJECT SCOPE]*
10	Autenticação utilizador	Autenticar o utilizador para acesso à aplicação de assinatura com Cartão de Cidadão ou CMD	eSign segue o flow imposto pela CMD, que implica autenticação prévia do utilizador.
11	Canal comunicação seguro	Usar canal seguro para transmissão de credenciais do utilizador a serviço CMD assinatura	*[TO BE ANSWERED BASED ON THE PROJECT SCOPE]* - Garantir que o eSign está exposto para fora com HTTPS + - Garantir que entre o eSign e os serviços da AMA não existem proxies ou outras componentes da arquitetura que possam captural involuntáriamente as credenciais do utilizador.
12	Dados a serem assinados (DTBS/R)	Apresentar os dados a serem assinados no formato XML (que contém o hash do documento a assinar em formato byte array) – também designado por representação dos dados a serem assinados (DTBS/R) – ao servidor de assinatura CMD da AMA, garantindo que corresponde aos dados/documento a assinar apresentado pelo/ao assinante. [cf. secção 3.1.2 da POL#16]	Sim. eSign segue as especificações impostas pelo serviço de SCMD, que implica passagem do hash do documento a ser assinado e respectivo contexto de operação.
13	Guardar a assinatura	É da responsabilidade das aplicações guardar a assinatura embebida no documento assinado com os dados assinados ou, guardar a assinatura separada dos dados assinados. [cf. secção 3.1.3 da POL#16]	eSign guarda a assinatura embebida no PDF assinado, de acordo com a norma PAdES.
14	Adicionar referência ao OID da política CMD	A guarda da assinatura é efetuada no formato, perfil e nível de assinatura definida pela aplicação (por exemplo, PAdES Basic, PAdES-EPES, …), sendo que o formato/perfil/nível utilizado deve permitir adicionar uma referência à Política CMD de Assinatura Qualificada (indicando pelo menos o seu OID 2.16.620.2.1.2.2), de modo a permitir que partes confiantes e outras pessoas interessadas possam encontrar informação sobre as políticas e práticas seguidas na aposição da assinatura. [cf. secção 3.1.3 da POL#16]	eSign segue as referências PAdES, no entanto não está a inserir a OID especificada.
15	Comunicação com o CMD	Comunicar com o SCMD, em conformidade com o protocolo SAP (cf. secção 3 da ?Declaração de Práticas de Operação do SCMD?) e com o manual de integração fornecido. [cf. secção 3.2.4 da POL#16]	eSign segue o flow imposto pela CMD/SCMD.
16	Apresentar os dados a assinar	Apresentar os dados a assinar de acordo com a política WYSIWYS (What You See Is What You Sign), diretamente na aplicação ou em aplicação externa [cf. secção 3.2.4 da POL#16]	Todas as assinaturas do tipo CMD realizadas no eSign são no contexto do documento que está no momento da assinatura a ser apresentado ao utilizador.
17	Adicionar compromissos assumidos pelo assinante ao efetuar a assinatura	Com a assinatura dos dados/documento, a aplicação deve permitir que o assinante associe ao campo Razão/Reason, um (ou vários) dos seguintes tipo de compromissos (e respetivo OID), de modo a contextualizar (e desambiguar) o propósito e significado da assinatura, assim como a natureza da responsabilidade assumida: Prova de origem / Proof of origin, Prova de aprovação / Proof of approval, Prova de criação / Proof of creation, Autenticação de dados / Data Autentication, Autenticação de Entidade / Entity Autentication, Autoria / Authorship, Revisão / Review, Cópia / Copy, Testemunha de assinatura / Signature Witness, Vinculação ao conteúdo assinado / Bound to data signed, Aprovação interm‚dia / Intermediate approval. [cf. secção 3.2.2 da POL#16]	*[TO BE ANSWERED BASED ON THE PROJECT SCOPE]* eSign permite customização de: - Campo "reason" das assinaturas - Campo "location" das assinaturas - Nome do processo a enviar no OTP da CMD [variable: ARTIFACT_NAME] É responsabilidade do projeto garantir o correto mapeamento destas configurações
18	Validação dos dados de identificação do documento	A aplicação possibilita que o assinante valide que os dados de identificação do documento, a assinar, recebidos na mensagem SMS/Push notification, são os mesmos que lhe são apresentados no user interface da aplicação. [cf. secção 3.2.4 da POL#16]	*[TO BE ANSWERED BASED ON THE PROJECT SCOPE]* (Ex: Mensagens enviadas para as notificação da CMD contêm o identificador único do documento que o assinante está a consultar (também visível no browser), assim como o identificador lógico do documento (friendly name) para contextualizar o cliente com a operação.) Acrescentar a variable 'ARTIFACT_NAME' aos documentos que requerem assinatura com CMD. O valor desta variável deverá dar contexto do que o cliente está prestes a aprovar, e será enviado para a AMA e apresentado no OTP da CMD enviado ao utilizador. Exemplo de valores: - "Ficha de Informação Individual" - "Processo 123456789"
19	Identificar os vários passos do processo de assinatura	Identificar e informar sobre os vários passos do processo de assinatura [cf. secção 3.2.4 da POL#16] à medida que os mesmo ocorrem.	eSign guia o utilizador da inserção dos dados necessários à assinatura, com o respectivo contexto (consultar video de evidência em anexo).
20	Identificar o passo a partir do qual a assinatura será criada	Identificar claramente o passo a partir do qual a assinatura será criada, garantindo que o assinante conhece a responsabilidade assumida no ato de assinar e que fica vinculado a essa responsabilidade e ao compromisso assumido [cf. secção 3.2.4 da POL#16]	eSign fornece contexto visual sobre o documento e campo a ser assinado, e garante que o ato de assinatura é uma acção explicita do utilizador (consultar video de evidência em anexo).
21	Guiar o assinante na guarda da assinatura	Guiar o assinante na guarda da assinatura embebida no documento assinado com os dados assinados ou, na guarda da assinatura separada dos dados assinados. [cf. secção 3.2.4 da POL#16]	eSign guia o utilizador da inserção dos dados necessários à assinatura, com o respectivo contexto (consultar video de evidência em anexo).
22	Proper Advice And Information Required	A aplicação fornece ao assinante informação e conselho relativo ao processo de criação de assinatura e consequências legais, assim como garantir na extensão possível, que o interface do utilizar fornece um ambiente legal válido para assinatura [cf. secção 4.2.1 da POL#16] Deve para tal ser assegurado que: - informação sobre o processo de criação de assinatura e conselho sobre como o deve fazer - ou seja dizer como deve utilizar a app para fazer uma assinatura - informação sobre as consequências legais da assinatura - i.e., que qualquer assinatura feita pela app tem valor legal de acordo com a lei X e com o regulamento UE 910/2014 - para o interface fornecer um ambiente legal válido para assinatura, têm que: (Para mais detalhes vida POL#16 em https://www.autenticacao.gov.pt/cmd-assinatura)	*[TO BE ANSWERED BASED ON THE PROJECT SCOPE]*
23	Aprovação AMA	A disponibilização da aplicação, bem como qualquer alteração ou nova versão, com funcionalidades de CMD assinatura apenas pode ser disponibilizada após submissão à AMA de relatório com evidências de cada um dos pontos supra, aprovação pela AMA e sua publicação em https://www.autenticacao.gov.pt/	OK
24	Cifrar no cliente o nº de telemóvel, PIN e OTP inserido	Cifrar no dispositivo cliente (e.g., recorrendo a código que corra na aplicação ou browser do cliente - e.g., javascript) com chave publica disponibilizada pela AMA o telemovel, PIN e OTP inserido pelo utilizador.	A recolha de quaisquer dados confidenciais nunca é feita a descoberto, sendo realizada com campo standard próprios para o efeito; nomeadamente campos HTML5 do tipo password. Adicionalmente, os pins e otp’s, além de cifrados via comunicação HTTPS são cifrados com a chave pública da AMA no browser, o que permite que um ataque de man-in-the-middle não tenha acesso às credenciais do utilizador a descoberto. Como layer de segurança adicional, e a fim de impedir que um pin cifrado possa ser apanhado por um ataque de man-in-the-middle e reutilizado em futuras chamadas diretas aos serviços da AMA, é ainda aplicado ao transporte entre o frontend e o backend do eSign uma cifra com uma chave de sessão única do eSign. À chegada ao backend e imediatamente antes da integração com os serviços da AMA a cifra de sessão do eSign é removida, sendo a cifra da AMA é mantida ponto-a-ponto.

Guideline

Description

Recommended Response

PIN CMD por assinatura

Exigir a introdução do PIN da CMD por cada assinatura ou batch de assinatura efetuada. Não o guardando na BD ou em sessão.

Quaisquer tipo de credenciais relacionadas com CMD (tlm, pin, …) não são persistidos em qualquer tipo de repositório, e mesmo em sessão e memória encontram-se obfuscados.

Documento a assinar visivel

Apresentar sempre o documento a assinar pelo cidadão.

Todas as assinaturas do tipo CMD realizadas no eSign são no contexto do documento que está no momento da assinatura a ser apresentado ao utilizador.

Dispositivos seguros

Não permitir a instalação da aplicação em dispositivos comprometidos

[TO BE ANSWERED BASED ON THE PROJECT SCOPE]

PIN CMD não visivel

Não apresentar visivel para o utilizador os digitos do PIN da CMD

A recolha de quaisquer dados confidenciais nunca é feita a descoberto, sendo realizada com campos standard próprios para o efeito; nomeadamente campos HTML5 do tipo password. Adicionalmente, os pins e otp’s, além de cifrados via comunicação HTTPS são cifrados com a chave pública da AMA no browser, o que permite que um ataque de man-in-the-middle não tenha acesso às credenciais do utilizador a descoberto. Como layer de segurança adicional, e a fim de impedir que um pin cifrado possa ser apanhado por um ataque de man-in-the-middle e reutilizado em futuras chamadas diretas aos serviços da AMA, é ainda aplicado ao transporte entre o frontend e o backend do eSign uma cifra com uma chave de sessão única do eSign. À chegada ao backend (e imediatamente antes da integração com os serviços da AMA) a cifra de sessão do eSign é removida, sendo a cifra da AMA é mantida ponto-a-ponto.
- eSign Frontend: cifra_esign_session[cifra_ama[pin]]
- eSign Backend: cifra_ama[pin]
- AMA: cifra_ama[pin]

PIN CMD não guardado localmente

Não guardar nos logs os dados do PIN ou Pin temporário

O produto eSign não guarda, em qualquer altura, logs com dados sensíveis da CMD. eSign utiliza ainda a versão mais recente da assinatua com CMD (SCMD), com o propósito de garantir que mesmo com logs de rede e infraestrutura não capturam os dados sensíveis a descoberto.
Para este efeito os PINs são cifrados ainda no client-side com a chave pública da AMA chave pública de sessão e uma chave de sessão do próprio produto eSign, a fim de garantir que mesmo que estes sejam apanhados na rede (interna ou externa) não poderão ser decifrados.

Guarda de evidência

O eSign guarda evidência do par User+OTP, com o objectivo de, em caso de disputa legal, existirem evidencias da informação que foi introduzida pelo cliente para se poder fazer cross-check com o que chegou à AMA.
De notar que credenciais reutilizáveis (pin) nunca são logadas nem persistidas de qualquer forma pelo eSign.
A evidencia do User+OTP (cifrados com a chave pública da AMA) é guardada dentro do PDF assinado e nas tabelas de auditoria da aplicação. De notar que o código OTP apenas é guardado após ser consumido pelo serviço da AMA, garantindo que não pode ser reutilizado.

[TO BE ANSWERED BASED ON THE PROJECT SCOPE - JUSTIFY THAT NETWORK AND FIREWALLS WILL NOT DECODE HTTPS AND LOG THE INCOMING MESSAGES]

PIN CMD não transmitido

Não transmitir para qualquer outra aplicação dados do PIN da CMD ou PIN temporário (além da aplicação da CMD)

Dados sensíveis de CMD são utilizados numa óptica de fire-and-forget, não sendo persistidos nem transmitidos a mais nenhuma entidade que não a aplicação de CMD.

Comprometimento aplicação

Em caso de compromentimento da aplicação informar a AMA num prazo inferior a 4 horas (após conhecimento do incidente de segurança).

[TO BE ANSWERED BASED ON THE PROJECT SCOPE]

Atualização aplicação

Detetar a existência de novas versões da aplicação e permitir a atualização automatica da aplicação

A aplicação eSign é uma web app, não existindo distribuição de binários para os utilizadores finais.

Credenciais autenticação aplicação

Não partilhar as credenciais de acesso a aplicação a serviço CMD assinatura com qualquer outra entidade ou aplicação

[TO BE ANSWERED BASED ON THE PROJECT SCOPE]

Autenticação utilizador

Autenticar o utilizador para acesso à aplicação de assinatura com Cartão de Cidadão ou CMD

eSign segue o flow imposto pela CMD, que implica autenticação prévia do utilizador.

Canal comunicação seguro

Usar canal seguro para transmissão de credenciais do utilizador a serviço CMD assinatura

[TO BE ANSWERED BASED ON THE PROJECT SCOPE]

- Garantir que o eSign está exposto para fora com HTTPS +
- Garantir que entre o eSign e os serviços da AMA não existem proxies ou outras componentes da arquitetura que possam captural involuntáriamente as credenciais do utilizador.

Dados a serem assinados (DTBS/R)

Apresentar os dados a serem assinados no formato XML (que contém o hash do documento a assinar em formato byte array) – também designado por representação dos dados a serem assinados (DTBS/R) – ao servidor de assinatura CMD da AMA, garantindo que corresponde aos dados/documento a assinar apresentado pelo/ao assinante. [cf. secção 3.1.2 da POL#16]

Sim. eSign segue as especificações impostas pelo serviço de SCMD, que implica passagem do hash do documento a ser assinado e respectivo contexto de operação.

Guardar a assinatura

É da responsabilidade das aplicações guardar a assinatura embebida no documento assinado com os dados assinados ou, guardar a assinatura separada dos dados assinados. [cf. secção 3.1.3 da POL#16]

eSign guarda a assinatura embebida no PDF assinado, de acordo com a norma PAdES.

Adicionar referência ao OID da política CMD

A guarda da assinatura é efetuada no formato, perfil e nível de assinatura definida pela aplicação (por exemplo, PAdES Basic, PAdES-EPES, …), sendo que o formato/perfil/nível utilizado deve permitir adicionar uma referência à Política CMD de Assinatura Qualificada (indicando pelo menos o seu OID 2.16.620.2.1.2.2), de modo a permitir que partes confiantes e outras pessoas interessadas possam encontrar informação sobre as políticas e práticas seguidas na aposição da assinatura. [cf. secção 3.1.3 da POL#16]

eSign segue as referências PAdES, no entanto não está a inserir a OID especificada.

Comunicação com o CMD

Comunicar com o SCMD, em conformidade com o protocolo SAP (cf. secção 3 da ?Declaração de Práticas de Operação do SCMD?) e com o manual de integração fornecido. [cf. secção 3.2.4 da POL#16]

eSign segue o flow imposto pela CMD/SCMD.

Apresentar os dados a assinar

Apresentar os dados a assinar de acordo com a política WYSIWYS (What You See Is What You Sign), diretamente na aplicação ou em aplicação externa [cf. secção 3.2.4 da POL#16]

Todas as assinaturas do tipo CMD realizadas no eSign são no contexto do documento que está no momento da assinatura a ser apresentado ao utilizador.

Adicionar compromissos assumidos pelo assinante ao efetuar a assinatura

Com a assinatura dos dados/documento, a aplicação deve permitir que o assinante associe ao campo Razão/Reason, um (ou vários) dos seguintes tipo de compromissos (e respetivo OID), de modo a contextualizar (e desambiguar) o propósito e significado da assinatura, assim como a natureza da responsabilidade assumida: Prova de origem / Proof of origin, Prova de aprovação / Proof of approval, Prova de criação / Proof of creation, Autenticação de dados / Data Autentication, Autenticação de Entidade / Entity Autentication, Autoria / Authorship, Revisão / Review, Cópia / Copy, Testemunha de assinatura / Signature Witness, Vinculação ao conteúdo assinado / Bound to data signed, Aprovação interm‚dia / Intermediate approval. [cf. secção 3.2.2 da POL#16]

[TO BE ANSWERED BASED ON THE PROJECT SCOPE]

eSign permite customização de:
- Campo "reason" das assinaturas
- Campo "location" das assinaturas
- Nome do processo a enviar no OTP da CMD [variable: ARTIFACT_NAME]

É responsabilidade do projeto garantir o correto mapeamento destas configurações

Validação dos dados de identificação do documento

A aplicação possibilita que o assinante valide que os dados de identificação do documento, a assinar, recebidos na mensagem SMS/Push notification, são os mesmos que lhe são apresentados no user interface da aplicação. [cf. secção 3.2.4 da POL#16]

[TO BE ANSWERED BASED ON THE PROJECT SCOPE]

(Ex: Mensagens enviadas para as notificação da CMD contêm o identificador único do documento que o assinante está a consultar (também visível no browser), assim como o identificador lógico do documento (friendly name) para contextualizar o cliente com a operação.)

Acrescentar a variable 'ARTIFACT_NAME' aos documentos que requerem assinatura com CMD. O valor desta variável deverá dar contexto do que o cliente está prestes a aprovar, e será enviado para a AMA e apresentado no OTP da CMD enviado ao utilizador. Exemplo de valores:
- "Ficha de Informação Individual"
- "Processo 123456789"

Identificar os vários passos do processo de assinatura

Identificar e informar sobre os vários passos do processo de assinatura [cf. secção 3.2.4 da POL#16] à medida que os mesmo ocorrem.

eSign guia o utilizador da inserção dos dados necessários à assinatura, com o respectivo contexto (consultar video de evidência em anexo).

Identificar o passo a partir do qual a assinatura será criada

Identificar claramente o passo a partir do qual a assinatura será criada, garantindo que o assinante conhece a responsabilidade assumida no ato de assinar e que fica vinculado a essa responsabilidade e ao compromisso assumido [cf. secção 3.2.4 da POL#16]

eSign fornece contexto visual sobre o documento e campo a ser assinado, e garante que o ato de assinatura é uma acção explicita do utilizador (consultar video de evidência em anexo).

Guiar o assinante na guarda da assinatura

Guiar o assinante na guarda da assinatura embebida no documento assinado com os dados assinados ou, na guarda da assinatura separada dos dados assinados. [cf. secção 3.2.4 da POL#16]

eSign guia o utilizador da inserção dos dados necessários à assinatura, com o respectivo contexto (consultar video de evidência em anexo).

Proper Advice And Information Required

A aplicação fornece ao assinante informação e conselho relativo ao processo de criação de assinatura e consequências legais, assim como garantir na extensão possível, que o interface do utilizar fornece um ambiente legal válido para assinatura [cf. secção 4.2.1 da POL#16] Deve para tal ser assegurado que:

- informação sobre o processo de criação de assinatura e conselho sobre como o deve fazer - ou seja dizer como deve utilizar a app para fazer uma assinatura
- informação sobre as consequências legais da assinatura - i.e., que qualquer assinatura feita pela app tem valor legal de acordo com a lei X e com o regulamento UE 910/2014
- para o interface fornecer um ambiente legal válido para assinatura, têm que: (Para mais detalhes vida POL#16 em https://www.autenticacao.gov.pt/cmd-assinatura)

[TO BE ANSWERED BASED ON THE PROJECT SCOPE]

Aprovação AMA

A disponibilização da aplicação, bem como qualquer alteração ou nova versão, com funcionalidades de CMD assinatura apenas pode ser disponibilizada após submissão à AMA de relatório com evidências de cada um dos pontos supra, aprovação pela AMA e sua publicação em https://www.autenticacao.gov.pt/

Cifrar no cliente o nº de telemóvel, PIN e OTP inserido

Cifrar no dispositivo cliente (e.g., recorrendo a código que corra na aplicação ou browser do cliente - e.g., javascript) com chave publica disponibilizada pela AMA o telemovel, PIN e OTP inserido pelo utilizador.

A recolha de quaisquer dados confidenciais nunca é feita a descoberto, sendo realizada com campo standard próprios para o efeito; nomeadamente campos HTML5 do tipo password. Adicionalmente, os pins e otp’s, além de cifrados via comunicação HTTPS são cifrados com a chave pública da AMA no browser, o que permite que um ataque de man-in-the-middle não tenha acesso às credenciais do utilizador a descoberto. Como layer de segurança adicional, e a fim de impedir que um pin cifrado possa ser apanhado por um ataque de man-in-the-middle e reutilizado em futuras chamadas diretas aos serviços da AMA, é ainda aplicado ao transporte entre o frontend e o backend do eSign uma cifra com uma chave de sessão única do eSign. À chegada ao backend e imediatamente antes da integração com os serviços da AMA a cifra de sessão do eSign é removida, sendo a cifra da AMA é mantida ponto-a-ponto.