Histórico da Página

Informações Gerais

Objetivo

Homologar a integração do TSA com o protocolo REP PrintPoint III, biometria padrão sagem e versão da aplicação do dispositivo 02.02.0000. Este protocolo atende Integrar o TSA ao Henry Hexa, atendendo ao protocolo com as especificações da portaria do Inmetro.

Definição da Regra de Negócio

O referido protocolo do REP PrintPoint III é uma evolução adaptação do protocolo do REP PrintPoint II contendo algumas particularidades descritas logo abaixo8X para a portaria do Inmetro. O protocolo 8X já está implementado para os equipamentos Henry Prisma e SuperFácil. Todas as funcionalidades existentes no PII 8X devem coexistir no PIIIno Hexa. Os comandos devem ser reutilizados, a comunicação (ListenerSender) deve ser totalmente separada devido ao controle de sessão presente no Hexa. O acoplamento das duas integrações será alto em termos de comandos. Este alto acoplamento se justifica devido ao alto grau de semelhança entre os protocolos. Em termos de comunicação (envio e recebimento de comandos) esse acoplamento será baixo, pois, cada integração deverá possuir o seu listenerSender. Esta implementação do listenerSender deverá possuir uma classe genérica utilizando-se do design pattern template method, assim, implementará somente o que for de sua responsabilidade. Com um listenerSender genérico será possível desenvolver futuras integrações com mais flexibilidade e agilidade.

 

Particularidades a implementar:

 

1. Criptografia

   1. Implementar comando

f7h: O comando f7h é o envio da chave de sessão. A chave de sessão basicamente consiste em enviar ao REP uma chave privada AES/ECB de 256 bits (gerada pelo TSA) junto com um login e senha de autenticação no dispositivo. De acordo com a Dimep, todos os PIII vem de fabrica com o login sendo "login" e senha sendo "senha".
 

Apesar do protocolo PIII possuir um comando de alteração do login e senha, este não será implementado. O próprio fornecedor não recomenda que o login e senha do dispositivo sejam alterados, pois, caso isso ocorra, e, seja esquecido os novos valores, não será possível recuperar (resetar) este login e senha. Dessa forma, se o cliente desejar um login e senha diferente ao padrão de fabrica, ele deverá fazer esta solicitação a Dimep. Se isto ocorrer, no lado do TSA, bastará ir nas configurações do dispositivo e alterar os campos de login e senha do mesmo.

 Por fim, este pacote f7h deve ser enviado ao REP criptografado usando para isso uma chave publica RSA de 1024 bits.

 A chave publica é fornecida pelo PIII através da função 45 digitada no relógio. Também é possível regerar a chave publica do REP através da função 46 digitada no relógio. Quando isso ocorrer, será necessário extrair a nova chave pela função 45 e informa-la nas configurações do dispositivo nos respectivos campos

1. 1. RA e EA: A mensagem RA pede ao dispositivo qual a chave pública RSA do equipamento. A chave RSA é utilizada apenas para criptografar a chave de sessão que é enviada na sequência ao equipamento gerada pelo próprio TSA. O Fluxo segue a seguinte regra:

       - Requisição RA → Pede ao equipamento qual a chave pública

       - Resposta RA ← Recebe a chave RSA 1024 encriptada em Base64

       - TSA Gera uma chave AES 128

       - Requisição EA → Envia ao REP qual a chave que o TSA irá se comunicar com o equipamento durante a sessão, junto com um login e senha de autenticação no dispositivo.

       - Resposta EA ← Com o retorno de recebimento positivo o TSA deve iniciar a sessão de comunicação para que os próximos comandos sejam enviados ou recebidos.

      
      

      Implementar codificação dos demais pacotes: Após

envio do comando f7h, todos os demais pacotes que o TSA enviar ao REP deverão ser criptografados usando a chave privada enviada no comando f7h. Assim como

1. 1. o início da sessão, o TSA terá em sua memória a chave AES gerada, a partir disso, todas mensagens enviadas ao equipamento, já codificadas para Prisma e SuperFácil, deverão ser criptografadas e "encodadas" em Base64. E todas as respostas do REP ao TSA serão descriptografadas usando esta mesma chave. A conexão entre o REP e o TSA será fechada sempre que não houver mais pacotes a serem enviados/recebidos. Dessa forma, quando existir um novo comando a ser enviado o TSA irá enviar novamente o comando

f7h

1. 1. RA e o ciclo se reinicia. A chave

privada

1. 1. simétrica AES 128 enviada no comando

f7h

1. 1. EA deve ser regerada de tal forma que a cada nova conexão com o REP se tenha uma nova chave privada, garantindo assim, ainda mais segurança.

 
Atualizar política de segurança da JRE: A política de segurança padrão do JRE não permite usar chaves AES de 256 bits. Para que isso ocorra, o JRE do TSA deve ter sua política de segurança atualizada. Além disso, deve-se implementar um método que verifique se o integrador está com essa política atualizada. Se negativo, deve gerar um erro orientando como atualizar a política. Mais detalhes em

1. 1. 
      
      

2. Criar usuário:
   

   Para o cliente configurar um usuário e senha, o cliente deve criar estes usuários primeiramente nos equipamentos. Para isso, o cliente deve:

   1. Acessar o IP do equipamento pelo Browser (Ex: http://

www

1. 1. 192.168.

oracle

1. 1. 10.

com/technetwork/java/javase/downloads/jce-6-download-429243.html.

1. 1. 10/)

   2. Se logar utilizando o usuário: rep e a senha: 123456. 

   3. Com este usuário e senha já de fábrica, o cliente deve criar um novo usuário e uma nova senha para que o TSA se comunique com o equipamento

   4. Configurar na tela de manutenção de dispositivos do TSA o usuário e senha configurado no equipamento

   Observação: O usuário rep não é autorizado para efetuar a comunicação entre o TSA e o equipamento, por isso tem a necessidade de manualmente criar os usuários e senhas

CPF Responsável:

No protocolo do PIII os comandos a seguir tiveram adicionados no final de seus pacotes mais um campo contendo o numero do CPF do responsável pelas alterações na MRP do REP: C1h - Atualiza data hora, C6h - Atualiza funcionário, C8h - Atualiza credenciais, E1h - Insere ou remove digitais e D4h - Altera dados empregador. Assim, para não mexer na assinatura desses comandos o listenerSender do PIII deve antes de enviar ao REP sobrescreve-los adicionando no final do pacote o campo contendo o CPF do responsável pelo REP.

 

Se o CPF não for informado ou o valor informado for diferente de 11 dígitos, deve ser lançado um erro no log do integrador com a mensagem: "CPF do responsável pelo REP (informado na configuração do dispositivo) deve ter 11 dígitos! Valor informado: [valor]".

Não será feita validação no numero do CPF. Sendo de responsabilidade do cliente informar um valor válido
1. .

1. Biometria:

   • No protocolo PIII os comandos do protocolo PII de recebimento (2Ah) e inclusão/exclusão (C9h) de biometria foram descontinuados. Agora é necessário usar os comandos 35h (recebimento de template genérico) e E1h (envio/exclusão de template genérico). As diferenças entre os novos comandos e os antigos são bastante sutis, dessa forma deve-se continuar usando os comandos do PII, porem, quando o comando for enviado ao PIII o listenerSender deve adicionar essas diferenças no pacote. Do mesmo modo, quando uma digital for recebida ela deve ser gravada no banco no mesmo padrão que o PII reconhece.

      

     As digitais que foram cadastradas usando um REP Printpoint II, poderão ser atualizadas no REP Printpoint III. Desde que o módulo biométrico seja do mesmo tipo e possua a mesma sensibilidade de leitura.

      

     Este requisito homologa apenas o padrão biométrico sagem.

 

 

Dicionário de Dados

Para conseguir usar o PrintPoint III na versão 12.1.9, será necessário rodar o script abaixo: