DECISÃO 2008/616/JAI DO CONSELHO

de 23 de Junho de 2008

referente à execução da Decisão 2008/615/JAI, relativa ao aprofundamento da cooperação transfronteiras, em particular no domínio da luta contra o terrorismo e da criminalidade transfronteiras

O CONSELHO DA UNIÃO EUROPEIA,

Tendo em conta o artigo 33.o da Decisão 2008/615/JAI do Conselho (1),

Tendo em conta a iniciativa da República Federal da Alemanha,

Tendo em conta o parecer do Parlamento Europeu (2),

Considerando o seguinte:

Em 23 de Junho de 2008, o Conselho aprovou a Decisão 2008/615/JAI relativa ao aprofundamento da cooperação transfronteiras, em particular no domínio da luta contra o terrorismo e da criminalidade transfronteiras.

Pela Decisão 2008/615/JAI, foram transpostos para o quadro jurídico da União Europeia os elementos fundamentais do Tratado de 27 de Maio de 2005 entre o Reino da Bélgica, a República Federal da Alemanha, o Reino de Espanha, a República Francesa, o Grão-Ducado do Luxemburgo, o Reino dos Países Baixos e a República da Áustria, relativo ao Aprofundamento da Cooperação Transfronteiras, em particular no domínio da Luta contra o Terrorismo, a Criminalidade Transfronteiras e a Migração Ilegal (a seguir designado «Tratado de Prüm»).

O artigo 33.o da Decisão 2008/615/JAI estabelece que incumbe ao Conselho aprovar as medidas necessárias à execução da Decisão 2008/615/JAI ao nível da União, nos termos da segunda frase da alínea c) do n.o 2 do artigo 34.o do Tratado da União Europeia. Essas medidas deverão basear-se no Acordo de Execução, de 5 de Dezembro de 2006, relativo à execução administrativa e técnica e à aplicação do Tratado de Prüm.

A presente decisão estabelece as disposições normativas comuns indispensáveis à execução administrativa e técnica das formas de cooperação previstas na Decisão 2008/615/JAI. O anexo da presente decisão contém disposições de execução de natureza técnica. Além disso, será elaborado e regularmente actualizado pelo Secretariado-Geral do Conselho um manual separado, que conterá informações exclusivamente factuais a fornecer pelos Estados-Membros.

Tendo em conta as capacidades técnicas, as consultas de rotina de novos perfis de ADN serão, em princípio, efectuadas por meio de consultas únicas, e serão encontradas a nível técnico soluções adequadas para o efeito,

DECIDE:

CAPÍTULO 1

GENERALIDADES

Artigo 1.o

Objectivo

O objectivo da presente decisão é estabelecer as disposições administrativas e técnicas necessárias à execução da Decisão 2008/615/JAI, especialmente no que respeita ao intercâmbio automatizado de dados de ADN, dados dactiloscópicos e dados relativos ao registo de veículos, como previsto no capítulo 2 da referida decisão, e a outras formas de cooperação previstas no capítulo 5 da mesma.

Artigo 2.o

Definições

Para efeitos da presente decisão, entende-se por:

«Dados relativos ao registo de veículos», conjunto dos dados tal como especificado no capítulo 3 do anexo da presente decisão;

«Caso concreto», a que se referem a segunda frase do n.o 1 do artigo 3.o, a segunda frase do n.o 1 do artigo 9.o e o n.o 1 do artigo 12.o da Decisão 2008/615/JAI, designa uma única investigação ou um único procedimento penal. Se tal ficheiro contiver mais do que um perfil de ADN, dado dactiloscópico ou dado relativo ao registo de veículos, esses perfis ou dados podem ser transmitidos conjuntamente num único pedido de consulta.

CAPÍTULO 2

DISPOSIÇÕES COMUNS EM MATÉRIA DE INTERCÂMBIO DE DADOS

Artigo 3.o

Especificações técnicas

Os Estados-Membros observam as especificações técnicas comuns correspondentes a todos os pedidos e respostas associados às consultas e comparações de perfis de ADN, dados dactiloscópicos e dados relativos ao registo de veículos. Essas especificações técnicas são definidas no anexo da presente decisão.

Artigo 4.o

Rede de comunicações

O intercâmbio electrónico, entre Estados-Membros, de dados de ADN, dados dactiloscópicos e dados relativos ao registo de veículos efectua-se através da rede de comunicações «Serviços Telemáticos Transeuropeus Seguros entre Administrações» (TESTA II) e suas versões mais recentes.

Artigo 5.o

Disponibilidade de intercâmbio de dados automatizados

Os Estados-Membros tomam todas as medidas necessárias para garantir que a consulta ou a comparação automatizada de dados de ADN, dados dactiloscópicos e dados relativos ao registo de veículos seja possível 24 horas por dia, 7 dias por semana. Na eventualidade de uma falha técnica, os pontos de contacto nacionais dos Estados-Membros devem comunicar imediatamente entre si e acordar num sistema de intercâmbio de informações alternativo, a título temporário, em conformidade com as disposições jurídicas aplicáveis. O intercâmbio automatizado dos dados deve ser restabelecido o mais rapidamente possível.

Artigo 6.o

Índices de referência dos dados de ADN e dados dactiloscópicos

Os índices de referência, referidos nos artigos 2.o e 8.o da Decisão 2008/615/JAI, consistem na combinação dos seguintes elementos:

No que respeita aos dados de ADN, um código indicativo do tipo de perfil de ADN.

CAPÍTULO 3

DADOS DE ADN

Artigo 7.o

Princípios que regem o intercâmbio de dados de ADN

1. Os Estados-Membros utilizam as normas existentes em matéria de intercâmbio de dados de ADN, como a Série-Padrão Europeia (ESS) ou o Conjunto Normalizado de Loci da Interpol (ISSOL).

2. O procedimento de transmissão, em caso de consulta automatizada ou de comparação automatizada de perfis de ADN, efectua-se no quadro de uma estrutura descentralizada.

3. São tomadas medidas adequadas para assegurar a confidencialidade e a integridade dos dados transmitidos a outros Estados-Membros, incluindo a sua cifragem.

4. Cada Estado-Membro toma as medidas necessárias para garantir a integridade dos perfis de ADN disponibilizados ou transmitidos aos restantes Estados-Membros para efeitos de comparação, e para assegurar que essas medidas sejam conformes com as normas internacionais, como a ISO 17025.

5. Os Estados-Membros utilizam os códigos «Estados-Membros» em conformidade com a norma ISO 3166-1 alpha-2.

Artigo 8.o

Regras aplicáveis aos pedidos e respostas relativos aos dados de ADN

1. O pedido de consulta ou comparação automatizada, a que se referem os artigos 3.o e 4.o da Decisão 2008/615/JAI, inclui unicamente as seguintes informações:

2. A resposta (relatório de concordância) dada ao pedido, a que se refere o n.o 1, inclui unicamente as seguintes informações:

Os códigos «Estado-Membro» do Estado-Membro requerente e do Estado-Membro requerido;

Os índices de referência do Estado-Membro requerente e do Estado-Membro requerido;

3. A notificação automatizada de uma concordância só pode ser efectuada se da consulta ou comparação automatizada tiver resultado a concordância de um número mínimo de loci. Esse mínimo é fixado no capítulo 1 do anexo da presente decisão.

4. Os Estados-Membros devem certificar-se de que os pedidos são conformes com as declarações comunicadas em aplicação do n.o 3 do artigo 2.o da Decisão 2008/615/JAI. Essas declarações constam do manual a que se refere o n.o 2 do artigo 18.o da presente decisão.

Artigo 9.o

Procedimento de transmissão aplicável à consulta automatizada de perfis de ADN não identificados a que se refere o artigo 3.o da Decisão 2008/615/JAI

1. Se, em caso de consulta a partir de um perfil de ADN não identificado, na base de dados nacional não se constatar qualquer concordância ou se constatar uma concordância com um perfil de ADN não identificado, o perfil de ADN não identificado pode ser transmitido a todas as bases de dados dos outros Estados-Membros; se, em caso de consulta a partir desse perfil de ADN não identificado, nas bases de dados de outros Estados-Membros se constatarem concordâncias com perfis de ADN de referência e/ou perfis de ADN não identificados, estas concordâncias são automaticamente comunicadas e os dados de ADN de referência são transmitidos ao Estado-Membro requerente. Se, nas bases de dados dos outros Estados-Membros, não se constatar qualquer concordância, o Estado-Membro requerente é automaticamente informado do facto.

2. Se, ao realizar uma consulta a partir de um perfil de ADN não identificado, for constatada uma concordância nas bases de dados de outros Estados-Membros, cada Estado-Membro interessado pode inserir uma anotação nesse sentido na sua base de dados nacional.

Artigo 10.o

Procedimento de transmissão aplicável à consulta automatizada de perfis ADN de referência a que se refere o artigo 3.o da Decisão 2008/615/JAI

Se, em consulta a partir de um perfil de ADN de referência, na base de dados nacional não se constatar qualquer concordância com um perfil de ADN de referência ou se constatar uma concordância com um perfil de ADN não identificado, o perfil de ADN de referência pode ser transmitido a todas as bases de dados dos outros Estados-Membros; se, em caso de consulta a partir desse perfil de ADN de referência, nas bases de dados de outros Estados-Membros se constatarem concordâncias com perfis de ADN de referência e/ou perfis de ADN não identificados, essas concordâncias são imediatamente comunicadas e os dados de ADN de referência são transmitidos ao Estado-Membro requerente. Se, nas bases de dados dos outros Estados-Membros, não se constatar qualquer concordância, o Estado-Membro requerente é automaticamente informado do facto.

Artigo 11.o

Procedimento de transmissão aplicável à comparação automatizada de perfis de ADN não identificados a que se refere o artigo 4.o da Decisão 2008/615/JAI

1. Se, numa comparação com perfis de ADN não identificados, nas bases de dados de outros Estados-Membros se constatarem concordâncias com perfis de ADN de referência e/ou perfis de ADN não identificados, essas concordâncias são automaticamente comunicadas e os dados de ADN de referência são transmitidos ao Estado-Membro requerente.

2. Se, numa comparação com perfis de ADN não identificados, nas bases de dados de outros Estados-Membros se constatarem concordâncias com perfis de ADN não identificados ou com perfis de ADN de referência, cada Estado-Membro interessado pode inserir uma anotação nesse sentido na sua base de dados nacional.

CAPÍTULO 4

DADOS DACTILOSCÓPICOS

Artigo 12.o

Princípios que regem o intercâmbio de dados dactiloscópicos

1. A digitalização dos dados dactiloscópicos e a respectiva transmissão aos restantes Estados-Membros efectuam-se em conformidade com o formato de dados uniforme especificado no capítulo 2 do anexo da presente decisão.

2. Cada Estado-Membro deve certificar-se de que os dados dactiloscópicos que transmite têm qualidade suficiente para serem comparados pelo Sistema Automático de Identificação Dactiloscópica (AFIS).

3. O procedimento de transmissão aplicável ao intercâmbio de dados dactiloscópicos efectua-se no quadro de uma estrutura descentralizada.

4. São tomadas medidas adequadas a fim de assegurar a confidencialidade e a integridade dos dados dactiloscópicos transmitidos aos outros Estados-Membros, incluindo a sua cifragem.

5. Os Estados-Membros utilizam os códigos «Estados-Membros» em conformidade com a norma ISO 3166-1 alpha-2.

Artigo 13.o

Capacidades de consulta para os dados dactiloscópicos

1. Cada Estado-Membro assegura que os respectivos pedidos de consulta não excedam as capacidades de consulta especificadas pelo Estado-Membro requerido. Os Estados-Membros apresentam ao Secretariado-Geral do Conselho as declarações a que se refere o n.o 2 do artigo 18.o, indicando as suas capacidades máximas de consulta diárias para os dados dactiloscópicos de pessoas identificadas e para os dados dactiloscópicos de pessoas ainda não identificadas.

2. O número máximo de candidatos admitidos para verificação por transmissão é fixado no capítulo 2 do anexo à presente decisão.

Artigo 14.o

Regras aplicáveis aos pedidos e respostas relativos aos dados dactiloscópicos

1. O Estado-Membro requerido controla imediatamente a qualidade dos dados dactiloscópicos transmitidos por processo totalmente automatizado. Caso os dados não se adequem a uma comparação automatizada, o Estado-Membro requerido deve informar imediatamente do facto o Estado-Membro requerente.

2. O Estado-Membro requerido efectua as consultas por ordem de chegada dos pedidos. Os pedidos devem ser tratados no prazo de 24 horas através de um processo totalmente automatizado. Se a sua legislação nacional o exigir, o Estado-Membro requerente pode solicitar o tratamento acelerado desses pedidos e o Estado-Membro requerido efectua imediatamente as referidas consultas. Se, por razões de força maior, os prazos não puderem ser respeitados, a comparação deve ser efectuada sem demora, logo que os obstáculos sejam ultrapassados.

CAPÍTULO 5

DADOS RELATIVOS AO REGISTO DE VEÍCULOS

Artigo 15.o

Princípios que regem a consulta automatizada de dados relativos ao registo de veículos

1. Para a consulta automatizada de dados relativos ao registo de veículos, os Estados-Membros utilizam uma versão da aplicação informática do Sistema Europeu de Informação sobre Veículos e Cartas de Condução (Eucaris), especialmente concebida para efeitos do artigo 12.o da Decisão 2008/615/JAI, e as versões alteradas desta aplicação informática.

2. A consulta automatizada de dados relativos ao registo de veículos efectua-se no quadro de uma estrutura descentralizada.

3. As informações intercambiadas através do Sistema Eucaris são cifradas.

4. Os elementos relativos ao registo de veículos que devem ser objecto de intercâmbio são especificados no capítulo 3 do anexo da presente decisão.

5. No quadro da execução do artigo 12.o da Decisão 2008/615/JAI, os Estados-Membros podem dar prioridade às consultas relacionadas com a luta contra a criminalidade grave.

Artigo 16.o

Custos

Os Estados-Membros suportam os custos relativos à administração, à utilização e à manutenção da aplicação informática Eucaris referida no n.o 1 do artigo 15.o.

CAPÍTULO 6

COOPERAÇÃO POLICIAL

Artigo 17.o

Patrulhas e outras intervenções conjuntas

1. Em conformidade com o capítulo 5 da Decisão 2008/615/JAI e, em particular, com as declarações apresentadas em aplicação do n.o 4 do artigo 17.o e dos n.os 2 e 4 do artigo 19.o da referida decisão, cada Estado-Membro designa um ou mais pontos de contacto a fim de dar aos outros Estados-Membros a possibilidade de se dirigirem às autoridades competentes e cada Estado-Membro pode especificar os procedimentos que aplica à organização de patrulhas e outras intervenções conjuntas e às iniciativas de outros Estados-Membros relativamente a essas intervenções, bem como outros aspectos práticos e modalidades operacionais a elas aplicáveis.

2. O Secretariado-Geral do Conselho elabora e actualiza a lista dos pontos de contacto e informa as autoridades competentes de todas as alterações nela introduzidas.

3. As autoridades competentes de cada Estado-Membro podem apresentar uma iniciativa com vista à organização de uma intervenção conjunta. Antes do início de uma intervenção específica, as autoridades competentes a que se refere o n.o 2 determinam, verbalmente ou por escrito, as disposições aplicáveis, que podem incluir as seguintes informações pormenorizadas:

As atribuições dos funcionários e outros agentes do ou dos Estados-Membros de origem no Estado-Membro de acolhimento durante a intervenção;

As armas, as munições e o equipamento específicos que os funcionários do Estado-Membro de origem podem utilizar durante a intervenção, em conformidade com a Decisão 2008/615/JAI;

4. As declarações, os procedimentos e as designações a que se refere o presente artigo são reproduzidos no manual referido no n.o 2 do artigo 18.o.

CAPÍTULO 7

DISPOSIÇÕES FINAIS

Artigo 18.o

Anexo e manual

1. Do anexo da presente decisão constam mais informações pormenorizadas para a execução técnica e administrativa da Decisão 2008/615/JAI.

2. O Secretariado-Geral do Conselho elabora e mantém actualizado um manual que contém informações exclusivamente factuais, fornecidas pelos Estados-Membros através de declarações feitas em aplicação da Decisão 2008/615/JAI ou da presente decisão ou através de notificações feitas ao Secretariado-Geral do Conselho. O manual tem a forma de um documento do Conselho.

Artigo 19.o

Autoridades independentes competentes em matéria da protecção de dados

Nos termos do n.o 2 do artigo 18.o da presente decisão, os Estados-Membros informam o Secretariado-Geral do Conselho sobre as autoridades independentes competentes em matéria de protecção de dados ou sobre as autoridades judiciárias a que se refere o n.o 5 do artigo 30.o da Decisão 2008/615/JAI.

Artigo 20.o

Preparação das decisões a que se refere o n.o 2 do artigo 25.o da Decisão 2008/615/JAI

1. O Conselho toma as decisões a que se refere o n.o 2 do artigo 25.o da Decisão 2008/615/JAI com base num relatório de avaliação que, por sua vez, se baseia num questionário.

2. No que respeita ao intercâmbio automatizado de dados previsto no capítulo 2 da Decisão 2008/615/JAI, o relatório de avaliação baseia-se também numa visita de avaliação e num ensaio-piloto a realizar quando o Estado-Membro em causa tiver tiver comunicado ao Secretariado-Geral as informações previstas na primeira frase do n.o 2 do artigo 36.o da Decisão 2008/615/JAI.

3. Do capítulo 4 do anexo da presente decisão constam mais informações pormenorizadas sobre este procedimento.

Artigo 21.o

Avaliação do intercâmbio de dados

1. É efectuada regularmente uma avaliação da aplicação, do ponto de vista administrativo, técnico e financeiro, do intercâmbio de dados previsto no capítulo 2 da Decisão 2008/615/JAI e, em particular, da utilização do mecanismo previsto no n.o 5 do artigo 15.o da referida decisão. A avaliação deve referir-se aos Estados-Membros que já apliquem a Decisão 2008/615/JAI no momento da sua realização e incidir nas categorias de dados em relação às quais tenha começado o intercâmbio entre os Estados-Membros em causa. A avaliação baseia-se em relatórios apresentados pelos Estados-Membros.

2. Do capítulo 4 do anexo da presente decisão constam mais informações pormenorizadas sobre este procedimento.

Artigo 22.o

Relação com o Acordo de Execução do Tratado de Prüm

Aos Estados-Membros vinculados pelo Tratado de Prüm aplicam-se as disposições relevantes da presente decisão e do seu anexo, depois de plenamente transpostas, em vez das disposições correspondentes do Acordo de Execução do Tratado de Prüm. Todas as outras disposições do Acordo de Execução continuam a ser aplicáveis entre as partes contratantes no Tratado de Prüm.

Artigo 23.o

Execução

Os Estados-Membros devem tomar as medidas necessárias para dar cumprimento às disposições da presente decisão nos prazos referidos no n.o 1 do artigo 36.o da Decisão 2008/615/JAI.

Artigo 24.o

Aplicação

A presente decisão produz efeitos vinte dias após a sua publicação no Jornal Oficial da União Europeia.

(1) Ver página 1 do presente Jornal Oficial.

(2) Parecer emitido em 21 de Abril de 2008 (ainda não publicado no Jornal Oficial).

ANEXO

ÍNDICE

CAPÍTULO 1: Intercâmbio de dados de ADN

1. Questões forenses relacionadas com o ADN, regras de concordância e algoritmos

1.1. Propriedades dos perfis de ADN

1.2. Regras de concordância

1.3. Regras de notificação

2. Tabela de códigos dos Estados-Membros

3. Análise funcional

3.1. Disponibilidade do sistema

3.2. Segundo passo

4. Documento de controlo da interface ADN

4.1. Introdução

4.2. Definição da estrutura XML

5. Arquitectura da aplicação, da segurança e da comunicação

5.1. Síntese

5.2. Arquitectura de nível superior

5.3. Normas de segurança e protecção de dados

5.4. Protocolos e normas a utilizar para o mecanismo de cifragem: sMIME e pacotes conexos

5.5. Arquitectura da aplicação

5.6. Protocolos e normas a utilizar na arquitectura da aplicação

5.7. Ambiente de comunicação

CAPÍTULO 2: Intercâmbio de dados dactiloscópicos (documento de controlo de interface)

1. Síntese do conteúdo do ficheiro

2. Formato dos registos

3. Registo lógico de tipo 1: cabeçalho do ficheiro

4. Registo lógico de tipo-2: texto descritivo

5. Registo lógico de tipo-4: imagens dactiloscópicas de alta resolução em escala de cinzentos

6. Registo lógico de tipo-9: registo de minúcias

7. Registo de tipo-13 de imagens latentes de resolução variável

8. Registo de tipo-15 de imagens palmares de resolução variável

9. Apêndices do capítulo 2 (intercâmbio de dados dactiloscópicos)

9.1. Apêndices 1. Códigos de separação ASCII

9.2. Apêndices 2. Cálculo do carácter de controlo alfanumérico

9.3. Apêndices 3. Códigos de caracteres

9.4. Apêndices 4. Sumário das transacções

9.5. Apêndices 5. Registo de tipo-1 — definições

9.6. Apêndices 6. Registo de tipo-2 — definições

9.7. Apêndices 7. Códigos de compressão em escala de cinzentos

9.8. Apêndices 8. Requisitos de correio electrónico

CAPÍTULO 3: Intercâmbio de dados relativos ao registo de veículos

1. Conjunto de dados comum para a busca automática de dados relativos ao registo de veículos

1.1. Definições

1.2. Busca de veículo/proprietário/detentor

2. Segurança da informação

2.1. Síntese

2.2. Elementos de segurança relacionados com o intercâmbio de mensagens

2.3. Elementos de segurança não relacionados com o intercâmbio de mensagens

3. Condições técnicas para o intercâmbio de dados

3.1. Descrição geral da aplicação Eucaris

3.2. Requisitos funcionais e não funcionais

CAPÍTULO 4 Avaliação

1. Procedimento de avaliação nos termos do artigo 20. o (preparação de decisões a que se refere o n. o 2 do artigo 25. o da Decisão 2008/615/JAI)

1.1. Questionário

1.2. Fase-piloto

1.3. Visita de avaliação

1.4. Relatório ao Conselho

2. Procedimento de avaliação nos termos do artigo 21. o

2.1. Estatísticas e relatório

2.2. Revisão

3. Reuniões de peritos

CAPÍTULO 1: Intercâmbio de dados de ADN

1. Questões forenses relacionadas com o ADN, regras de concordância e algoritmos

1.1. Propriedades dos perfis de ADN

O perfil de ADN pode incluir 24 pares de números que correspondem aos alelos de 24 loci, igualmente utilizados nos procedimentos da Interpol em matéria de ADN. As designações destes loci constam do seguinte quadro:

VWA TH01 D21S11 FGA D8S1179 D3S1358 D18S51 Amelogenina TPOX CSF1P0 D13S317 D7S820 D5S818 D16S539 D2S1338 D19S433 Penta D Penta E FES F13A1 F13B SE33 CD4 GABA

Os 7 loci sombreados na linha de cima correspondem ao actual conjunto normalizado europeu de loci (ESS) e ao conjunto normalizado de loci da Interpol (ISSOL).

Regras de inclusão:

Os perfis de ADN disponibilizados pelos Estados-Membros para efeitos de consulta ou comparação, bem como os perfis de ADN enviados para efeitos de consulta e comparação devem incluir pelo menos 6 loci plenamente designados (1), podendo conter loci suplementares ou espaços em branco em função da sua disponibilidade. Os perfis de ADN de referência devem conter pelo menos 6 dos 7 ESS de loci. A fim de aumentar o grau de exactidão das concordâncias, todos os alelos disponíveis devem ser armazenados na base de dados indexada de perfis de ADN para efeitos de busca e comparação. Os Estados-Membros devem implementar o mais rapidamente possível eventuais novos ESS de loci adoptados pela União Europeia.

Não são permitidos perfis mistos por forma a que os valores de alelos de cada locus consistam em apenas dois números que podem ser idênticos em caso de homozigotia em determinado locus.

Os jokers (wildcards) e as microvariantes devem ser abordados de acordo com as seguintes regras:

— Qualquer valor não numérico, com excepção da amelogenina, contido no perfil (por exemplo «o», «f», «r», «na», «nr» or «un») deve ser convertido automaticamente para exportação para um joker (*) e comparado com todos.

— Os valores numéricos «0», «1» ou «99» contidos no perfil devem ser convertidos automaticamente para exportação para um joker (*) e comparados com todos.

— Se para um locus forem facultados 3 alelos, o primeiro será aceite e os restantes 2 devem ser automaticamente convertidos para exportação para um joker (*) e comparados com todos.

— Se forem fornecidos valores joker para 1 ou 2 alelos, serão pesquisadas ambas as permutações do valor numérico dado para o locus (por exemplo, 12* pode corresponder a 12,14 ou 9,12).

— As microvariantes de pentanucleótidos (Penta D, Penta E & CD4) serão comparadas de acordo com o seguinte esquema: — x.1 = x, x.1, x.2 — x.2 = x.1, x.2, x.3 — x.3 = x.2, x.3, x.4 — x.4 = x.3, x.4, x + 1

— As microvariantes de tetranucleótidos (os restantes loci são tetranucleótidos) serão comparadas de acordo com o seguinte esquema: — x.1 = x, x.1, x.2 — x.2 = x.1, x.2, x.3 — x.3 = x.2, x.3, x + 1

1.2. Regras de concordância

A comparação de 2 perfis de ADN será efectuada com base nos loci para os quais exista um par de valores alélicos em ambos os perfis. Pelo menos 6 loci plenamente designados (sem amelogenina) devem corresponder nos dois perfis de ADN antes que seja dada uma resposta de acerto.

A concordância total (qualidade 1) é definida como a identidade de todos os valores de alelos dos loci comparados contidos nos perfis de ADN. A concordância quase total («near match») é definida como a concordância de todos menos um dos alelos comparados, contidos em 2 perfis de ADN (Qualidades 2, 3 e 4). As concordâncias quase totais apenas serão aceites se houver pelo menos uma concordância total de 6 loci plenamente designados, correspondentes nos 2 perfis de ADN comparados.

A causa de uma concordância quase total pode ser:

— Um erro de dactilografia na introdução de um dos perfis de ADN na consulta ou na base de dados de ADN;

— um erro de determinação ou designação de alelos durante o processo de geração do perfil de ADN.

1.3. Regras de notificação

Tanto as concordâncias totais como as quase totais e os «não acertos» serão notificados.

O relatório de concordância é enviado ao ponto de contacto nacional requerente e facultado ao ponto de contacto nacional requerido (a fim de que possa avaliar a natureza e o número de possíveis pedidos subsequentes relativos a outros dados pessoais disponíveis e outras informações relacionadas com o perfil de ADN que corresponde ao acerto de acordo com os artigos 5.o e 10.o da Decisão 2008/615/JAI do Conselho.

2. Tabela de códigos dos Estados-Membros

De acordo com a Decisão 2008/615/JAI, será utilizado o código ISO 3166-1 alpha-2 para a criação de nomes de domínio e outros parâmetros de configuração requeridos nas aplicações de intercâmbio de dados de ADN em rede fechada no âmbito de Prüm.

Os códigos ISO 3166-1 alpha-2 são os seguintes códigos dos Estados-Membros com duas letras.

Nomes dos Estados-Membros Código Nomes dos Estados-Membros Código Bélgica BE Luxemburgo LU Bulgária BG Hungria HU República Checa CZ Malta MT Dinamarca DK Países Baixos NL Alemanha DE Áustria AT Estónia EE Polónia PL Grécia EL Portugal PT Espanha ES Roménia RO França FR Eslováquia SK Irlanda IE Eslovénia SI Itália IT Finlândia FI Chipre CY Suécia SE Letónia LV Reino Unido UK Lituânia LT

3. Análise funcional

3.1. Disponibilidade do sistema

Os pedidos apresentados de acordo com o artigo 3.o da Decisão 2008/615/JAI devem dar entrada na base de dados em causa por ordem cronológica de chegada e as respostas devem chegar ao Estado-Membro requerente no espaço de 15 minutos a contar da entrada dos pedidos.

3.2. Segundo passo

Quando um Estado-Membro recebe uma notificação de concordância, cabe ao respectivo ponto de contacto nacional a responsabilidade pela comparação dos valores do perfil apresentado no pedido com os valores do ou dos perfis recebidos em resposta a fim de validar e controlar o valor de prova do perfil. Os pontos de contacto nacionais podem entrar em contacto directo para efeitos de validação.

Os procedimentos de auxílio judiciário começam após a validação de uma concordância existente entre dois perfis com base numa concordância total ou quase total apuradas durante o processo de consulta automatizado.

4. Documento de controlo da interface ADN

4.1. Introdução

4.1.1. Objectivos

Este capítulo define os requisitos que regem o intercâmbio de informações sobre perfis de ADN entre os sistemas de bases de dados de ADN de todos os Estados-Membros. Os campos de cabeçalho são definidos especificamente para o intercâmbio de dados de ADN no contexto de Prüm, a parte relativa aos dados baseia-se na parte relativa aos dados dos perfis de ADN no esquema XML definido para a passarela para o intercâmbio de dados de ADN da Interpol.

Os dados são trocados por SMTP (protocolo de transferência de correio electrónico) e outras tecnologias de ponta, através de um relé central de transmissão de correio disponibilizado pelo fornecedor de serviços da rede. O ficheiro XML é transportado como corpo da mensagem de correio.

4.1.2. Âmbito de aplicação

O presente ICD define apenas o conteúdo da mensagem (email). Todos os tópicos específicos de rede e de correio são definidos de modo uniforme de modo a que o intercâmbio de dados de ADN possa ter uma base técnica comum.

Alguns pontos importantes:

— formato do título da mensagem por forma a permitir o tratamento automático das mensagens;

— necessidade ou não de cifrar o conteúdo e, em caso afirmativo, quais os métodos a escolher;

— comprimento máximo das mensagens.

4.1.3. Estrutura e princípios XML

A mensagem XML envolve duas partes:

— a parte do cabeçalho com informações sobre a transmissão e

— a parte dos dados com as informações específicas sobre o perfil, bem como o próprio perfil.

Deve ser utilizado o mesmo esquema XML quer se trate de pedidos, quer de respostas.

Para efeitos de controlos completos de perfis de ADN não identificados (artigo 4.o da Decisão 2008/615/JAI) deve ser possível enviar um lote de perfis numa só mensagem. Deve ser definido um número máximo de perfis numa só mensagem. O número depende da dimensão máxima permitida de mensagem e deve ser definido após a selecção do servidor de correio.

Exemplo de XML:

<?version="1.0" standalone="yes">

<PRUEMDNAx xmlns:msxsl="urn:schemas-microsoft-com:xslt"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

<header>

(…)

</header>

<datas>

(…)

</datas>

[<datas>estrutura de dados repetida em caso de perfis múltiplos enviados numa mensagem (…) SMTP única, apenas permitida em caso de dados de acordo com o artigo 4.o]

</PRUEMDNA>

4.2. Definição da estrutura XML

As seguintes definições são apresentadas para efeitos de documentação e melhor legibilidade, a informação vinculativa real é fornecida num ficheiro em formato XML (PRUEM DNA.xsd).

4.2.1. Formato PRUEMDNAx

Contém os seguintes campos:

Fields Type Description header PRUEM_header Occurs: 1 datas PRUEM_datas Occurs: 1 ... 500

4.2.2. Conteúdo da estrutura do cabeçalho

4.2.2.1. Cabeçalho PRUEM Esta estrutura descreve o cabeçalho do ficheiro XML e é composta pelos seguintes campos: Fields Type Description direction PRUEM_header_dir Direction of message flow ref String Reference of the XML file generator String Generator of XML file schema_version String Version number of schema to use requesting PRUEM_header_info Requesting Member State info requested PRUEM_header_info Requested Member State info

4.2.2.2. PRUEM_header dir Tipo de dados constantes da mensagem, cujo valor pode ser: Value Description R Request A Answer

4.2.2.3. Cabeçalho PRUEM info Estrutura para identificar o Estado-Membro, bem como a data/hora da mensagem. Contém os seguintes campos: Fields Type Description source_isocode String ISO 3166-2 code of the requesting Member State destination_isocode String ISO 3166-2 code of the requested Member State request_id String unique Identifier for a request date Date Date of creation of message time Time Time of creation of message

4.2.3. Conteúdo dos dados dos perfis PRUEM

4.2.3.1. Dados PRUEM Esta estrutura descreve a parte dos dados de perfis em formato XML. Contém os seguintes campos: Fields Type Description reqtype PRUEM request type Type of request (Article 3 or 4) date Date Date profile stored type PRUEM_datas_type Type of profile result PRUEM_datas_result Result of request agency String Name of corresponding unit responsible for the profile profile_ident String Unique Member State profile ID message String Error Message, if result = E profile IPSG_DNA_profile If direction = A (Answer) AND result ≠ H (Hit) empty match_id String In case of a HIT PROFILE_ID of the requesting profile quality PRUEM_hitquality_type Quality of Hit hitcount Integer Count of matched Alleles rescount Integer Count of matched profiles. If direction = R (Request), then empty. If quality! = 0 (the original requested profile), then empty.

4.2.3.2. Modelo de pedido PRUEM Tipo de dados constantes da mensagem, cujo valor pode ser: Value Description 3 Requests pursuant to Article 3 of Decision 2008/615/JHA 4 Requests pursuant to Article 4 of Decision 2008/615/JHA

4.2.3.3. Tipo de qualidade do acerto PRUEM Value Description 0 Referring original requesting profile: Case «No Hit»: original requesting profile sent back only; Case «Hit»: original requesting profile and matched profiles sent back. 1 Equal in all available alleles without wildcards 2 Equal in all available alleles with wildcards 3 Hit with Deviation (Microvariant) 4 Hit with mismatch

4.2.3.4. Tipo de dados PRUEM Tipo de dados contidos na mensagem, cujo valor pode ser: Value Description P Person profile S Stain

4.2.3.5. Resultados dos dados PRUEM Tipo de dados contidos na mensagem, cujo valor pode ser: Value Description U Undefined, If direction = R (request) H Hit N No Hit E Error

4.2.3.6. Perfil de ADN IPSG Esta estrutura descreve o perfil ADN. Contém os seguintes campos: Fields Type Description ess_issol IPSG_DNA_ISSOL Group of loci corresponding to the ISSOL (standard group of Loci of Interpol) additional_loci IPSG_DNA_additional_loci Other loci marker String Method used to generate of DNA profile_id String Unique identifier for DNA profile

4.2.3.7. IPSG_DNA_ISSOL Estrutura com os loci do ISSOL (conjunto normalizado de loci da Interpol). Contém os seguintes campos: Fields Type Description vwa IPSG_DNA_locus Locus vwa th01 IPSG_DNA_locus Locus th01 d21s11 IPSG_DNA_locus Locus d21s11 fga IPSG_DNA_locus Locus fga d8s1179 IPSG_DNA_locus Locus d8s1179 d3s1358 IPSG_DNA_locus Locus d3s1358 d18s51 IPSG_DNA_locus Locus d18s51 amelogenin IPSG_DNA_locus Locus amelogin

4.2.3.8. IPSG_DNA_additional_loci Estrutura com os outros loci. Contém os seguintes campos: Fields Type Description tpox IPSG_DNA_locus Locus tpox csf1po IPSG_DNA_locus Locus csf1po d13s317 IPSG_DNA_locus Locus d13s317 d7s820 IPSG_DNA_locus Locus d7s820 d5s818 IPSG_DNA_locus Locus d5s818 d16s539 IPSG_DNA_locus Locus d16s539 d2s1338 IPSG_DNA_locus Locus d2s1338 d19s433 IPSG_DNA_locus Locus d19s433 penta_d IPSG_DNA_locus Locus penta_d penta_e IPSG_DNA_locus Locus penta_e fes IPSG_DNA_locus Locus fes f13a1 IPSG_DNA_locus Locus f13a1 f13b IPSG_DNA_locus Locus f13b se33 IPSG_DNA_locus Locus se33 cd4 IPSG_DNA_locus Locus cd4 gaba IPSG_DNA_locus Locus gaba

4.2.3.9. IPSG_DNA_locus Estrutura para descrever um locus. Contém os seguintes campos: Fields Type Description low_allele String Lowest value of an allele high_allele String Highest value of an allele

5. Arquitectura da aplicação, da segurança e da comunicação

5.1. Síntese

Para efeitos de implementação de aplicações destinadas ao intercâmbio de dados de ADN no âmbito da Decisão 2008/615/JAI, deve ser utilizada uma rede comum de comunicação restrita aos Estados-Membros. A fim de aproveitar esta infra-estrutura de comunicação comum de envio e recepção de pedidos e respostas de um modo mais eficaz, é adoptado um mecanismo assíncrono para transmitir pedidos de dados de ADN e dactiloscópicos em mensagens protegidas de correio electrónico SMPT. Para ir ao encontro de preocupações de segurança, será utilizado o mecanismo sMIME em extensão da funcionalidade SMPT a fim de estabelecer um verdadeiro túnel seguro de ponta a ponta através da rede.

A rede operacional TESTA (Trans European Services for Telematics between Administrations — Serviços telemáticos transeuropeus entre administrações) é utilizada como rede de comunicação para o intercâmbio de dados entre os Estados-Membros. A TESTA é gerida pela Comissão Europeia. Tendo em conta que as bases nacionais de ADN e os actuais pontos nacionais de acesso à rede TESTA podem encontrar-se em locais diferentes nos Estados-Membros, o acesso TESTA pode ser criado quer:

1) utilizando o ponto de acesso nacional existente ou estabelecendo um novo ponto de acesso nacional à TESTA; quer

2) estabelecendo uma ligação local segura entre o local onde se encontra e é gerida pelo serviço nacional competente a base de dados de ADN e o ponto de acesso nacional à TESTA.

Os protocolos e as normas utilizadas na implementação das aplicações decorrentes da Decisão 2008/615/JAI obedecem às normas abertas e cumprem os requisitos impostos pelos decisores políticos dos Estados-Membros em matéria de segurança.

5.2. Arquitectura de nível superior

No âmbito da Decisão 2008/615/JAI, cada Estado-Membro disponibilizará os seus dados de ADN para efeitos de intercâmbio e/ou de consulta por outros Estados-Membros em conformidade com o formato de dados normalizado comum. A arquitectura baseia-se num modelo de comunicação de qualquer a qualquer (any-to-any). Não há nenhum servidor central nem nenhuma base de dados centralizada para armazenar perfis de ADN.

Figura 1: Topologia do intercâmbio de dados de ADN

Sob reserva dos requisitos legais nacionais nos locais dos Estados-Membros, cada Estado-Membro pode determinar o tipo de equipamento e software que deve ser utilizado para que a configuração do seu sítio obedeça aos requisitos constantes da Decisão 2008/615/JAI.

5.3. Normas de segurança e protecção de dados

Foram analisados e implementados três níveis de segurança.

5.3.1. Nível de dados

Os dados de perfis de ADN transmitidos por cada Estado-Membro devem obedecer a uma norma comum de protecção de dados por forma a que os Estados-Membros requerentes recebam uma resposta que indique sobretudo se há acerto ou não (HIT NO-HIT), junto com um número de identificação em caso de acerto, mas que não deve conter nenhuma informação de carácter pessoal. A investigação subsequente à notificação de um acerto será conduzida a nível bilateral de acordo com a regulamentação jurídica e administrativa dos sítios dos Estados-Membros.

5.3.2. Nível de comunicação

As mensagens que contêm informação (requerente e de resposta) sobre perfis de ADN serão cifradas por um sistema de ponta compatível com as normas abertas, como as sMIME antes de serem enviadas para os sítios de outros Estados-Membros.

5.3.3. Nível de transmissão

Todas as mensagens cifradas com informações relativas a perfis de ADN serão transmitidas para sítios de outros Estados-Membros através de um sistema de tunelização privado administrado por um fornecedor de rede reconhecido a nível internacional e de ligações securizadas a este sistema sob responsabilidade nacional. Este sistema virtual de tunelização privado não tem nenhuma ligação à internet aberta.

5.4. Protocolos e normas a utilizar para o mecanismo de cifragem: sMIME e pacotes conexos

A norma aberta sMIME enquanto extensão da norma de correio electrónico SMTP será utilizada para cifrar mensagens com informações relativas a perfis de ADN. O protocolo sMIME (V3) permite dispor de recibos assinados, rótulos de segurança e listas de endereços e baseia-se na sintaxe de mensagens criptográficas (CMS), uma especificação IETF para as mensagens protegidas por cifragem. Pode igualmente ser utilizada para assinatura, conversão, autenticação ou cifragem electrónicas de qualquer forma de dados digitais.

O certificado subjacente utilizado pelo mecanismo sMIME deve obedecer à norma X.509. A fim de assegurar normas e procedimentos comuns a outras aplicações Prüm, as regras de tratamento para operações de cifragem sMIME ou que devam ser aplicados em diferentes ambientes COTS (disponíveis no comércio) são as seguintes:

— A sequência das operações é a seguinte: primeiro cifragem e depois assinatura;

— Para a cifragem simétrica e assimétrica, serão aplicados, respectivamente, os algoritmos criptográficos AES (Norma Avançada de Cifragem — Advanced Encryption Standard), com um comprimento de código de 256 bits, e RSA, com um comprimento de código de 1 024 bits;

— Será aplicado o algoritmo de sumário SHA-1.

A funcionalidade sMIME está integrada na grande maioria dos pacotes de software modernos de correio electrónico, nomeadamente Outlook, Mozilla Mail e Netscape Communicator 4.x e é compatível com todos os principais pacotes de software de correio electrónico.

Dada a sua fácil integração na infra-estrutura nacional TI de todos os sítios dos Estados-Membros, o sMIME foi seleccionado como mecanismo viável para a implementação do nível de segurança das comunicações. Todavia, a fim de alcançar o objectivo de «validação de conceito» de uma forma mais eficaz e de reduzir os custos, opta-se pela norma aberta API JavaMail para o protótipo do intercâmbio de dados de ADN. A API JavaMail permite a cifragem e a decifragem simples de mensagens de correio electrónico que utilizem s/MIME e/ou OpenPGP. O objectivo é de dispor de uma API única de fácil utilização para os clientes de correio electrónico que pretendam enviar e receber mensagens cifradas num dos dois formatos de cifragem de correio electrónico mais correntes. Por conseguinte, para satisfazer os requisitos da Decisão 2008/615/JAI, bastará qualquer aplicação avançada para o API JavaMail, como o Bouncy Castle JCE (Java Cryptographic Extension — extensão criptográfica JAVA), que será utilizada para implementar o sMIME como protótipo para o intercâmbio de dados de ADN entre todos os Estados-Membros.

5.5. Arquitectura da aplicação

Cada Estado-Membro fornecerá aos restantes Estados-Membros um conjunto de dados normalizados de perfis de ADN em conformidade com o actual ICD comum quer mediante um esquema lógico de cada base de dados nacional, quer criando uma base de dados física exportada (base de dados indexada).

Os quatro principais componentes: servidor de correio electrónico/sMIME, servidor de aplicação, zona de estrutura de dados para extracção/alimentação de dados e registo de entrada/saída de mensagens, e o motor de concordância aplicam toda a lógica de aplicação de uma forma independente do produto.

A fim de que todos os Estados-Membros possam integrar facilmente os componentes nos seus sítios nacionais, a funcionalidade comum especificada foi implementada através de componentes abertos que podem ser seleccionados por cada Estado-Membro em função da sua política e regulamentação nacionais em matéria de TI. Cada Estado-Membro pode escolher livremente o equipamento e a plataforma de software, incluindo a base de dados e os sistemas operativos, tendo em conta as características independentes a implementar para obter o acesso às bases de dados indexadas que contêm perfis de ADN abrangidas pela Decisão 2008/615/JAI.

Foi desenvolvido e testado com êxito na rede comum existente um protótipo para o intercâmbio de dados de ADN. A versão 1.0 foi introduzida no ambiente de produção e está ser utilizada nas operações correntes. Os Estados-Membros podem utilizar o produto que foi desenvolvido em conjunto, mas também podem desenvolver os seus próprios produtos. Os componentes do produto comum serão mantidos, adaptados e desenvolvidos no futuro em função das alterações dos requisitos TI, forenses e/ou de política funcional.

Figura 2: Diagrama da topologia da aplicação

5.6. Protocolos e normas a utilizar na arquitectura da aplicação:

5.6.1. XML

O intercâmbio de dados de ADN aproveitará plenamente o esquema XML na forma de anexo às mensagens de correio electrónico SMTP. A XML (eXtensible Markup Language — Linguagem de Marcação Expansível) é uma linguagem de marcação de uso geral recomendada pelo W3C (World Wide Web Consortium — Consórcio da Web) para a criação de linguagens de marcação especializadas, capaz de descrever muitos tipos diferentes de dados. A descrição do perfil de ADN que se presta ao intercâmbio entre todos os Estados-Membros foi efectuada com a XML e o esquema XML no documento ICD.

5.6.2. ODBC

A conectividade de bases de dados abertas (Open DataBase Connectivity) constitui um método normalizado de software API para aceder a sistemas de gestão de bases de dados que a torna independente das linguagens de programação, bases de dados e sistemas operativos. A ODBC tem contudo de algumas limitações: a administração de um grande número de máquinas-cliente pode implicar uma grande diversidade de pilotos e DLLs. Esta complexidade pode dificultar a administração do sistema.

5.6.3. JDBC

A conectividade de bases de dados Java (JDBC — Java DataBase Connectivity) é uma interface API da linguagem de programação Java que determina a forma como um cliente pode aceder a uma base de dados. Ao contrário da ODBC, a JDBC não requer a utilização de um certo conjunto de DLLs locais no sistema de secretária (desktop).

O diagrama seguinte descreve a lógica funcional do tratamento dos pedidos e respostas de perfis de ADN no sítio de cada Estado-Membro. Os fluxos dos pedidos e respostas interagem com a zona de dados neutra que comporta diferentes conjuntos de dados, com uma estrutura de dados comuns.

Figura 3: Diagrama do fluxo de dados da aplicação no sítio de cada Estado-Membro

5.7. Ambiente de comunicação

5.7.1. Rede comum de comunicações: TESTA e sua infra-estrutura de apoio

A aplicação destinada ao intercâmbio de dados de ADN aproveitará o correio electrónico, um mecanismo assíncrono, para o envio e recepção de pedidos e respostas entre Estados-Membros. Dado que todos os Estados-Membros dispõem de pelo menos um ponto nacional de acesso à rede TESTA, o intercâmbio dos dados de ADN processar-se-á através desta rede. A TESTA oferece uma série de serviços de valor acrescentado graças ao seu relé de correio electrónico. Para além de acolher caixas de correio específicas da TESTA, a infra-estrutura possibilita listas de distribuição de correio e opções de encaminhamento. Deste modo, a TESTA pode ser utilizada como central de compensação para mensagens dirigidas às administrações ligadas a domínios União Europeia. Também podem ser instalados programas antivírus.

O relé de correio TESTA está integrado numa plataforma hardware de alta disponibilidade nas instalações centrais da aplicação TESTA e é protegido por corta-fogo. Os serviços de nomes de domínio (DNS) da TESTA converterão os localizadores de recursos em endereços IP e ocultarão os elementos de endereço aos utilizadores e às aplicações.

5.7.2. Preocupações de segurança

O conceito de VPN (rede privada virtual) foi aplicado no âmbito da TESTA. A tecnologia utilizada para criar esta VPN será adaptada para poder suportar a norma MPLS (Multi-Protocol Label Switching) desenvolvida pelo Grupo de Missão de Engenharia da Internet (IETF).

A MPLS é uma norma IETF que acelera o fluxo de tráfico na rede ao evitar a análise de pacote pelos encaminhadores intermédios (hops). Isso é feito com base nas chamadas etiquetas que são apensas ao pacote pelos encaminhadores charneira da espinha dorsal (backbone), a partir da informação armazenada na base de informação que envia a informação (forwarding information base — FIB). As etiquetas são igualmente utilizadas para implementar redes privadas virtuais (VPN).

A MPLS associa as vantagens do encaminhamento da camada 3 às vantagens da comutação da camada 2. Dado que os endereços IP não são avaliados durante a transição na espinha dorsal, a MPLS não impõe nenhumas limitações de endereço IP.

Além disso, as mensagens de correio electrónico via TESTA serão protegidas pelo mecanismo de cifragem da sMIME. Sem conhecer a chave e possuir o devido certificado, ninguém pode decifrar as mensagens que circulam na rede.

5.7.3. Protocolos e normas a utilizar na rede de comunicações

5.7.3.1. SMTP O protocolo de transferência de correio electrónico (Simple Mail Transfer Protocol) é a norma de facto para a transmissão de correio electrónico na internet. O SMPT é um protocolo textual relativamente simples, em que são especificados um ou mais destinatários da mensagem, sendo depois enviado o texto da mensagem. O SMTP utiliza a porta TCP 25 conforme especificado pelo IETF. Para determinar o servidor SMPT para um dado nome de domínio, utiliza-se o registo MX (Mail Exchange – troca de correio electrónico) DNS (sistema de nomes de domínio). Uma vez que este protocolo se baseia exclusivamente em caracteres ASCII, era dificilmente compatível com ficheiros binários. Foram desenvolvidas normas como a norma MIME para codificar ficheiros binários com vista à sua transferência através do SMTP. Hoje em dia, a maior parte dos servidores SMTP aceita a extensão 8BITMIME e sMIME, o que permite o envio de ficheiros binários quase tão facilmente como o simples texto. As regras de tratamento das operações sMIME são descritas na secção dedicada a esta norma (ver capítulo 5.4). O SMPT é um protocolo de extracção (push) que não permite extrair mensagens a partir de um servidor remoto a pedido. Para o efeito, o cliente de correio electrónico deve utilizar o POP3 ou o IMAP. No âmbito da implementação do intercâmbio de dados de ADN, foi decidido utilizar o protocolo POP3.

5.7.3.2. POP Os clientes locais de correio electrónico utilizam a versão 3 do protocolo (POP3), um protocolo internet normalizado de aplicação em camada, para extrair mensagens de correio electrónico de um servidor remoto através de uma conexão TCP/IP. Ao usar o perfil SMTP Submit do protocolo SMTP, os clientes de correio electrónico enviam mensagens através da internet ou através de uma rede empresarial. A norma MIME é utilizada nos anexos e no texto não ASCII no correio electrónico. Embora nem o POP3 nem o SMPT requeiram mensagens electrónicas em formato MIME, praticamente todas as mensagens internet chegam em formato MIME, pelo que os clientes POP devem aceitar e utilizar essa norma. Todo o ambiente de comunicação da Decisão 2008/615/JAI incluirá por conseguinte os componentes POP.

5.7.4. Atribuição de endereços de rede

Ambiente operativo

Actualmente, a autoridade de registo IP europeia (RIPE) reservou um bloco específico da sub-rede da classe C à TESTA. De futuro, poderão ser atribuídos novos blocos de endereços à TESTA, se tal for necessário. A atribuição de endereços IP aos Estados-Membros baseia-se num esquema geográfico europeu. O intercâmbio de dados entre Estados-Membros no âmbito da Decisão 2008/615/JAI processa-se através de uma rede IP europeia logicamente fechada.

Ambiente de ensaio

A fim de providenciar as condições necessárias ao bom funcionamento quotidiano entre todos os Estados-Membros ligados, deve ser criado um ambiente de ensaio da rede fechada para novos Estados-Membros que estejam a preparar-se para participar nas operações. Foi definida uma ficha de parâmetros, incluindo endereços IP, parâmetros de rede, domínios de correio electrónico, bem como contas de utilizadores, que deve ser implementada no sítio do Estado-Membro correspondente. Além disso, foi criado um conjunto de perfis de ADN fictícios para efeitos de ensaio.

5.7.5. Parâmetros de configuração

É criado um sistema seguro de correio electrónico que utiliza o domínio eu-admin.net. Este domínio, bem como os endereços que lhe estão associados não será acessível a partir de uma localização não pertencente ao domínio europeu TESTA, visto que os nomes apenas são conhecidos do servidor DNS central da TESTA que se encontra protegido da internet.

O mapeamento destes endereços de sítios TESTA (nomes internet) para os respectivos endereços IP é efectuado pelo serviço DNS da TESTA. Para cada Domínio Local, será inserida uma entrada Correio neste servidor DNS central da TESTA, o que faz com que todas as mensagens de correio enviadas aos Domínios Locais TESTA sejam retransmitidas ao Relé de Correio central TESTA. Este Relé de Correio central TESTA reenvia depois as mesmas ao servidor de correio específico do Domínio Local, utilizando os endereços do Domínio Local. Ao encaminhar as mensagens desta forma, as informações críticas nelas contidas apenas passarão pela infra-estrutura fechada europeia e não pela internet insegura.

É necessário estabelecer subdomínios ( a negro e em itálico ) em todos os sítios de todos os Estados-Membros que obedecem à seguinte sintaxe:

«tipo de aplicação.pruem.código do Estado-Membro. eu-admin.net», onde

«código do Estado-Membro» corresponde ao código de duas letras do Estado-Membro (p.ex. AT, BE, etc.).

« tipo de aplicação » corresponde a: ADN e FP.

Aplicando a sintaxe acima descrita, os subdomínios de cada Estado-Membro são enumerados no seguinte quadro:

MS Sub Domains Comments BE dna.pruem.be.eu-admin.net Setting up a secure local link to the existing TESTA II access point fp.pruem.be.eu-admin.net BG dna.pruem.bg.eu-admin.net fp.pruem.bg.eu-admin.net CZ dna.pruem.cz.eu-admin.net fp.pruem.cz.eu-admin.net DK dna.pruem.dk.eu-admin.net fp.pruem.dk.eu-admin.net DE dna.pruem.de.eu-admin.net Using the existing TESTA II national access points fp.pruem.de.eu-admin.net EE dna.pruem.ee.eu-admin.net fp.pruem.ee.eu-admin.net IE dna.pruem.ie.eu-admin.net fp.pruem.ie.eu-admin.net EL dna.pruem.el.eu-admin.net fp.pruem.el.eu-admin.net ES dna.pruem.es.eu-admin.net Using the existing TESTA II national access point fp.pruem.es.eu-admin.net FR dna.pruem.fr.eu-admin.net Using the existing TESTA II national access point fp.pruem.fr.eu-admin.net IT dna.pruem.it.eu-admin.net fp.pruem.it.eu-admin.net CY dna.pruem.cy.eu-admin.net fp.pruem.cy.eu-admin.net LV dna.pruem.lv.eu-admin.net fp.pruem.lv.eu-admin.net LT dna.pruem.lt.eu-admin.net fp.pruem.lt.eu-admin.net LU dna.pruem.lu.eu-admin.net Using the existing TESTA II national access point fp.pruem.lu.eu-admin.net HU dna.pruem.hu.eu-admin.net fp.pruem.hu.eu-admin.net MT dna.pruem.mt.eu-admin.net fp.pruem.mt.eu-admin.net NL dna.pruem.nl.eu-admin.net Intending to establish a new TESTA II access point at the NFI fp.pruem.nl.eu-admin.net AT dna.pruem.at.eu-admin.net Using the existing TESTA II national access point fp.pruem.at.eu-admin.net PL dna.pruem.pl.eu-admin.net fp.pruem.pl.eu-admin.net PT dna.pruem.pt.eu-admin.net … fp.pruem.pt.eu-admin.net … RO dna.pruem.ro.eu-admin.net fp.pruem.ro.eu-admin.net SI dna.pruem.si.eu-admin.net … fp.pruem.si.eu-admin.net … SK dna.pruem.sk.eu-admin.net fp.pruem.sk.eu-admin.net FI dna.pruem.fi.eu-admin.net [To be inserted] fp.pruem.fi.eu-admin.net SE dna.pruem.se.eu-admin.net fp.pruem.se.eu-admin.net UK dna.pruem.uk.eu-admin.net fp.pruem.uk.eu-admin.net

CAPÍTULO 2: Intercâmbio de dados dactiloscópicos (documento de controlo de interface)

O objectivo do documento de controlo de interface que se segue consiste em definir os requisitos para o intercâmbio de informação dactiloscópica entre os Sistemas Automáticos de Identificação Dactiloscópica (AFIS) dos Estados-Membros. Baseia-se na implementação pela Interpol da ANSI/NIST-ITL 1-2000 (INT-I, Versão 4.22b).

Esta versão abrangerá todas as definições básicas dos registos lógicos de tipo-1, tipo-2, tipo-4, tipo-9, tipo-13 e tipo-15 necessários para o tratamento dactiloscópico de imagens e minúcias.

1. Síntese do conteúdo do ficheiro

Um ficheiro dactiloscópico consiste em vários registos lógicos. Existem dezasseis tipos de registos especificados na norma ANSI/NIST-ITL 1-2000 original. Entre cada registo e os campos e subcampos no interior dos registos são utilizados caracteres de separação ASCII adequados.

São utilizados apenas 6 tipos de registos para o intercâmbio entre os organismos de origem e de destino:

Tipo-1 → Informação sobre a transacção Tipo-2 → Dados alfanuméricos relativos a pessoas/casos Tipo-4 → Imagens dactiloscópicas de elevada resolução em escala de cinzentos Tipo-9 → Registo de minúcias Tipo-13 → Registo de imagens latentes de resolução variável Tipo-15 → Registo de imagens palmares de resolução variável

1.1. Tipo-1 — Cabeçalho do ficheiro

Este registo contém informações de encaminhamento e informações descritivas da estrutura do restante ficheiro. Este tipo de registo define também os tipos de transacção que integram as seguintes grandes categorias:

1.2. Tipo-2 — Texto descritivo

Este registo contém texto com interesse para os organismos de envio e recepção.

1.3. Tipo-4 — Imagem em escala de cinzentos de elevada resolução

Este registo é utilizado para o intercâmbio de imagens dactiloscópicas de alta resolução em escala de cinzentos (8 bits) captadas a 500 píxeis/polegada. As imagens dactiloscópicas serão comprimidas usando o algoritmo WSQ com um rácio máximo de compressão de 15:1. Não podem ser utilizados outros algoritmos de compressão nem imagens não comprimidas.

1.4. Tipo-9 — Registo de minúcias

Os registos do tipo-9 são utilizados para trocar características das cristas ou minúcias. Destinam-se, por um lado, a evitar duplicações desnecessárias de processos de codificação AFIS e, por outro lado, a permitir a transmissão de códigos AFIS que contêm menos dados do que as imagens correspondentes.

1.5. Tipo-13 — Registo de imagens latentes de resolução variável

Este registo deve ser utilizado para o intercâmbio de imagens latentes de impressões digitais e palmares de resolução variável, juntamente com informações textuais alfanuméricas. A resolução das imagens deve ser de 500 píxeis/polegada com 256 tonalidades de cinzento. Se a qualidade da imagem latente for suficiente, deve ser comprimida utilizando o algoritmo WSQ. Se necessário, a resolução das imagens pode ser aumentada para mais de 500 píxeis/polegada e mais de 256 tonalidades de cinzento mediante acordo bilateral. Nesse caso, recomenda-se vivamente a utilização da norma JPEG 2000 (ver apêndice 7).

1.6. Registo de imagens palmares de resolução variável

Os registos de imagens em campo etiquetado do tipo-15 devem ser utilizados para o intercâmbio de imagens palmares de resolução variável, juntamente com informações textuais alfanuméricas. A resolução das imagens deve ser de 500 píxeis/polegada com 256 tonalidades de cinzento. Para minimizar o volume de dados, todas as imagens palmares devem ser comprimidas utilizando o algoritmo WSQ. Se necessário, a resolução das imagens pode ser aumentada para mais de 500 píxeis/polegada e mais de 256 tonalidades de cinzento mediante acordo bilateral. Nesse caso, recomenda-se vivamente a utilização da norma JPEG 2000 (ver apêndice 7).

2. Formato dos registos

Um ficheiro de transacção consistirá em um ou mais registos lógicos. Para cada registo lógico contido no ficheiro, devem existir vários campos de informação adequados. Cada campo de informação pode incluir um ou mais elementos básicos de informação com um só valor. Agrupados estes elementos são utilizados para transmitir diferentes aspectos dos dados incluídos nesse campo. Os campos de informação podem igualmente incluir um ou mais elementos de informação agrupados e repetidas várias vezes no interior de um campo. Este grupo de elementos de informação é conhecido como subcampo. Os campos de informação podem, portanto, incluir um ou mais subcampos de elementos de informação.

2.1. Separadores de informação

Nos registos lógicos com campos etiquetados, a informação é delimitada mediante o uso de quatro separadores de informação ASCII. A informação delimitada pode consistir em elementos no interior de um campo ou subcampo, campos no interior de um registo lógico ou múltiplas ocorrências de subcampos. Estes separadores de informação são definidos na norma ANSI X3.4. Estes caracteres são utilizados para separar e qualificar a informação de um modo lógico. Numa relação hierárquica, o carácter «FS» (separador de ficheiro) é o mais abrangente, seguido pelo separador de grupo «GS», o separador de registos «RS» e, por último, os caracteres de separação de unidades «US». O quadro 1 lista estes separadores ASCII e descreve o seu uso no âmbito desta norma.

Os separadores de informação devem ser encarados do ponto de vista funcional como uma indicação do tipo de dados que se segue. O caracter «US» deve separar elementos individuais de informação no interior de um campo ou subcampo. Assinala-se deste modo que o elemento de informação que se segue pertence a este campo ou subcampo. Os subcampos múltiplos no interior de um campo separados pelo caracter «RS» indicam o início do novo grupo de elementos de informação repetidos. O separador «GS» entre campos de informação indica o início de um novo campo que precede o número de identificação do campo que se segue. Do mesmo modo, o início de um novo registo lógico será assinalado pela ocorrência do separador «FS».

Os quatro caracteres apenas têm significado como separadores de elementos de dados nos campos de registo de texto ASCII. Estes caracteres não possuem qualquer significado específico quando surgem em registos de imagens e campos binários, sendo apenas parte dos dados trocados.

Regra geral, não deverá haver campos ou elementos de informação vazios, pelo que deverá surgir apenas um caracter de separação entre dois elementos de dados. Existe uma excepção a essa regra quando os dados nos campos ou elementos de informação numa transacção não estiverem disponíveis, faltem ou sejam facultativos e o tratamento da transacção não depender da presença destes dados específicos. Nesses casos, surgirão caracteres de separação múltiplos e adjacentes, não sendo necessário inserir dados fictícios entre eles.

Para efeitos de definição de um campo composto por três elementos de informação, aplica-se o seguinte: se faltar o segundo elemento de informação, ocorrem dois separadores «US» adjacentes entre o primeiro e o terceiro elemento de informação. Se faltarem tanto o segundo como o terceiro elemento de informação, deverão ser usados três separadores — dois separadores «US» mais o separador que encerra o campo ou subcampo. Em suma, se faltarem num campo ou subcampo um ou mais elementos de informação obrigatórios ou facultativos, deverão ser inseridos separadores tantas vezes quanto apropriado.

Por conseguinte, é possível que se sucedam combinações de dois ou mais dos quatro separadores disponíveis. Quando faltam ou não estão disponíveis dados para certos elementos de informação, subcampos ou campos, terá de haver um separador a menos que o total exigido de elementos de informação, subcampos ou campos.

Quadro 1: Separadores utilizados

Code Type Description Hexadecimal Value Decimal Value US Unit Separator Separates information items 1F 31 RS Record Separator Separates subfields 1E 30 GS Group Separator Separates fields 1D 29 FS File Separator Separates logical records 1C 28

2.2. Formato de registo

No que respeita aos registos lógicos em campos etiquetados, cada campo de informação utilizado deve ser numerado de acordo com esta norma. Cada campo será formatado com o número de tipo de registo lógico, seguido de um ponto «.», um número de campo seguido de dois pontos «:», seguido da informação apropriada a esse campo. O número do campo etiquetado pode ser qualquer algarismo de 0 a 9 entre o ponto «.» e os dois pontos «:» e será interpretado como um número de campo inteiro não sinalizado. Isto significa que um número de campo «2.123» equivale e é interpretado do mesmo modo que um número de campo «2.000000123:».

Para efeitos de ilustração no presente documento, será utilizado um número de três algarismos para enumerar os campos constantes de cada registo lógico descrito. Os números de campo terão o formato «TT.xxx:», sendo «TT» o tipo de registo de um ou dois caracteres seguido de um ponto. Os três caracteres seguintes constituem o número de campo adequado seguido de dois pontos, seguidos de informação descritiva ASCII ou dos dados relativos à imagem.

Os registos lógicos do tipo-1 e do tipo-2 contêm apenas campos de dados com texto ASCII. O comprimento total do registo (incluindo números de campo, dois pontos e caracteres de separação) será inscrito como primeiro campo ASCII em cada um destes tipos de registos. Os caracteres «FS» do separador de ficheiro ASCII (que representam o fim do registo lógico ou transacção) vêm a seguir ao último byte de informação ASCII e são incluídos no comprimento do registo.

Ao contrário do conceito de campo etiquetado, o registo de tipo-4 apenas contém dados binários registados como campos binários ordenados de comprimento fixo. Todo o comprimento do registo será inscrito no primeiro campo binário de quatro bytes de cada registo. Neste registo binário, não serão inscritos nem o número de registo com o seu ponto nem o número identificador de campo com os seus dois pontos. Além disso, uma vez que todos os comprimentos de campo deste registo são fixados ou especificados, os quatro separadores («US», «RS», «GS», ou «FS») só podem ser interpretados como sendo dados binários. No registo binário, o caracter «FS» não será utilizado como separador nem como carácter de fim de transacção.

3. Registo lógico de tipo 1: cabeçalho do ficheiro

Este registo descreve a estrutura e o tipo do ficheiro, bem como outras informações importantes. O conjunto de caracteres utilizado para campos do tipo-1 apenas contém o código ANSI de 7 bits para o intercâmbio de informações.

3.1. Campos para o registo lógico de tipo-1

3.1.1. Campo 1.001: comprimento de registo lógico (LEN — Logical Record Length)

Este campo contém o número total de bytes em todo o registo lógico do tipo-1. O campo começa com «1.001:» seguido do comprimento total do registo incluindo todos os caracteres de todos os campos e os separadores de informação.

3.1.2. Campo 1.001: número de versão (VER)

Para assegurar que os utilizadores conheçam a versão da norma ANSI/NIST que está a ser utilizada, este campo de quatro bytes especifica o número da versão da norma que está a ser aplicada pelo software ou pelo sistema de cria o ficheiro. Os dois primeiros bytes especificam o número de referência da versão principal e os dois segundos, o número de revisão menor. Por exemplo, a norma original de 1986 será considerada a primeira versão e designada por «0100» ao passo que a actual norma ANSI/NIST-ITL 1-2000 tem a designação de «0300».

3.1.3. Campo 1.003: conteúdo do ficheiro (CNT)

Este campo enumera cada um dos registos no ficheiro de acordo com o tipo e a ordem pela qual os registos aparecem no ficheiro lógico. Consistem em um ou mais subcampos que contêm dois elementos de informação descritivos de um registo lógico único encontrado no ficheiro. Os subcampos são introduzidos pela ordem em que os registos são introduzidos e transmitidos.

O primeiro elemento de informação no primeiro subcampo é o «1» e identifica o registo do tipo-1. Segue-se um segundo elemento de informação que contém o número de outros registos incluídos no ficheiro. Este número corresponde ao número de subcampos restantes do campo 1.003.

Cada um dos subcampos restantes está associado a um registo no ficheiro e a sequência de subcampos corresponde à sequência dos registos. Cada subcampo contém dois elementos de informação: o primeiro identifica o tipo de registo; o segundo corresponde ao IDC do registo. O caracter «US» deve ser utilizado para separar os dois elementos de informação.

3.1.4. Campo 1.004: tipo de transacção (TOT)

Este campo contém uma mnemónica que designa o tipo de transacção. Estes códigos podem ser diferentes dos utilizados por outras aplicações da norma ANSI/NIST.

CPS: busca de impressão em contexto penal (CPS — Criminal Print-to-Print Search). Esta transacção é um pedido de pesquisa numa base de dados de impressões digitais de um registo relacionado com uma infracção penal. As impressões digitais da pessoa devem ser incluídas no ficheiro como imagens WSQ comprimidas.

Em caso de não acerto (No-Hit), serão devolvidos os seguintes registos lógicos:

— 1 registo de tipo-1

— 1 registo de tipo-2

Em caso de acerto (HIT), serão devolvidos os seguintes registos lógicos:

— 1 registo de tipo-1

— 1 registo de tipo-2

— 1-14 registos de tipo-4

Consta do Quadro A.6.1 (Apêndice 6) um resumo do TOT CPS.

PMS: pesquisa impressão digital-latente. Recorre-se a esta transacção quando um conjunto de impressões digitais é comparado com uma base de dados de Latentes Não Identificadas. A resposta conterá o resultado Acerto/Não acerto da busca do AFIS de destino. Caso existam latentes não identificados múltiplos, serão devolvidas transacções SER múltiplas, cada uma com uma imagem latente. As impressões digitais da pessoa devem ser incluídas no ficheiro como imagens WSQ comprimidas.

Em caso de não acerto, a resposta incluirá os seguintes registos lógicos:

— 1 registo de tipo-1

— 1 registo de tipo-2

Em caso de acerto, a resposta incluirá os seguintes registos lógicos:

— 1 registo de tipo-1

— 1 registo de tipo-2

— 1 registo de tipo-13

Consta do Quadro A.6.1 (Apêndice 6) um resumo do TOT PMS.

MPS: pesquisa imagem latente — impressões digitais. Esta transacção é utilizada para comparar uma imagem latente com as impressões digitais contidas numa base de dados. Os pormenores da imagem latente e a imagem (comprimida com o algoritmo WSQ) devem ser incluídos no ficheiro.

Em caso de não acerto, a resposta incluirá os seguintes registos lógicos:

— 1 registo de tipo-1

— 1 registo de tipo-2

Em caso de acerto, a resposta incluirá os seguintes registos lógicos:

— 1 registo de tipo-1

— 1 registo de tipo-2

— 1 registo do tipo-4 ou do tipo-15

Consta do Quadro A.6.4 (Apêndice 6) um resumo do TOT MSP.

MMS: pesquisa imagem latente — imagem latente. Nesta transacção, o ficheiro contém uma imagem latente que deve ser conferida com uma base de dados de imagens latentes não identificadas a fim de estabelecer relações entre os vários locais do crime. Os pormenores da imagem latente e a imagem (comprimida com o algoritmo WSQ) devem ser incluídas no ficheiro.

Em caso de não acerto, a resposta incluirá os seguintes registos lógicos:

— 1 registo de tipo-1

— 1 registo de tipo-2

Em caso de acerto, a resposta incluirá os seguintes registos lógicos:

— 1 registo de tipo-1

— 1 registo de tipo-2

— 1 registo de tipo-13

Consta do Quadro A.6.4 (Apêndice 6) um resumo do TOT MMS.

SRE: esta transacção constitui a resposta do serviço de destino a pedidos com dados dactiloscópicos. A resposta incluirá o resultado acerto/não acerto da pesquisa AFIS na base de dados de destino. Caso existam candidatos múltiplos, serão devolvidas transacções SRE múltiplas, cada uma com um candidato.

Consta do Quadro A.6.2 (Apêndice 6) um resumo do TOT SRE.

ERR: esta transacção constitui a resposta do AFIS de destino para assinalar erros na transacção. Inclui um campo (ERM) para indicar o erro que foi detectado. Serão enviados os seguintes registos lógicos:

— 1 registo de tipo-1

— 1 registo de tipo-2

Consta do Quadro A.6.3 (Apêndice 6) um resumo do TOT ERR.

Quadro 2: Códigos admissíveis nas transacções

Transaction Type Logical Record Type 1 2 4 9 13 15 CPS M M M — — — SER M M C — (C in case of latent hits) C C MPS M M — M (1*) M — MMS M M — M (1*) M — PMS M M M* — — M* ERR M M — — — —

Chave:

M = obrigatório M* = apenas um dos dois tipos de registo pode ser incluído O = facultativo C = em função dos dados disponíveis — = não permitido 1* = em função dos sistemas herdados

3.1.5. Campo 1.005: data de transacção (DOT)

Este campo indica a data em que a transacção foi iniciada e deve obedecer ao formato-padrão da ISSO: AAAAMMDD

sendo AAAA o ano, MM o mês e DD o dia do mês. Números com apenas um algarismo são precedidos de «0». Por exemplo «19931004» corresponde a 4 de Outubro de 1993.

3.1.6. Campo 1.006: prioridade (PRY)

Este campo facultativo define a prioridade do pedido numa escala de 1 a 9. «1» corresponde à prioridade máxima e «9» à mais baixa. As transacções com prioridade «1» devem ser tratadas imediatamente.

3.1.7. Campo 1.007: identificador do serviço de destino (DAI)

Este campo indica o serviço de destino da transacção.

É composto por dois elementos de informação no seguinte formato: CC/organismo.

O primeiro elemento contém o código de país, definido na norma 3166 da ISO, de dois caracteres alfanuméricos. O segundo, organismo, destina-se à identificação do organismo em texto livre com um número máximo de 32 caracteres alfanuméricos.

3.1.8. Campo 1.008: identificador do organismo de origem (ORI)

Este campo identifica o originador do ficheiro e tem o mesmo formato que o DAI (campo 1.007).

3.1.9. Campo 1.009: número de controlo da transacção (TCN)

Trata-se de um número de controlo para efeitos de referência. Deve ser gerado pelo computador e ter o seguinte formato: YYSSSSSSSSA

sendo YY o ano da transacção, SSSSSSSS um número de série de oito algarismos e A uma letra de controlo gerada de acordo com o procedimento apresentado no Apêndice 2.

Na ausência de TCN, o campo YYSSSSSSSS é preenchido com zeros e a letra de controlo gerada de acordo com o procedimento acima descrito.

3.1.10. Campo 1.010: resposta de controlo da transacção (TCR)

Este campo facultativo contém o número de controlo da transacção da mensagem do pedido na resposta. Por conseguinte, apresenta o mesmo formato que o TCN (campo 1.009).

3.1.11. Campo 1.011: resolução de varrimento de origem (NSR)

Este campo indica a resolução de varrimento normal do sistema suportado pelo originador da transacção. Esta resolução é especificada com dois algarismos seguidos de um ponto decimal e mais dois algarismos.

Para todas as transacções efectuadas nos termos da Decisão 2008/615/JAI a taxa de amostragem deve ser de 500 píxeis/polegada ou 19,68 píxeis/mm.

3.1.12. Campo 1.012: resolução de transmissão nominal (NSR)

Este campo de cinco bytes especifica a resolução de transmissão normal para a transmissão das imagens. A resolução é expressa em píxeis/mm no mesmo formato que o NSR (campo 1.011).

3.1.13. Campo 1.013: nome de domínio (DOM)

Este campo obrigatório identifica o nome de domínio para a implementação do registo lógico de tipo-2 definido pelo utilizador. É composto por dois elementos de informação no seguinte formato: «INT-I{US}4.22{GS}».

3.1.14. Campo 1.014: Tempo Médio de Greenwich (GMT)

Este campo obrigatório prevê um mecanismo que permite indicar a data e a hora nas unidades universais do tempo médio de Greenwich (GMT). Quando utilizado, o campo GMT contém a data universal que constará para além da data local do campo 1.005 (DAT). A utilização do campo GMT elimina incoerências locais de tempo que surgem quando uma transacção e a respectiva resposta são transmitidas entre dois lugares separados por vários fusos horários. O GMT permite a indicação da data universal e das horas com relógio de 24 horas independentes dos fusos horários. É representado por «CCYYMMDDHHMMSSZ», uma sequência de 15 caracteres que corresponde à concatenação da data com o GMT e termina com a letra «Z». Os caracteres «CCYY» representam o ano da transacção, os caracteres «MM» as dezenas e unidades do mês e os caracteres «DD» as dezenas e unidades do dia do mês; os caracteres «HH» representam a hora, «MM» os minutos e «SS» os segundos. A data completa não deve exceder a data corrente.

4. Registo lógico de tipo-2: texto descritivo

A estrutura da maior parte deste registo não é definida pela norma ANSI/NIST original. O registo contém informação de interesse específico para os serviços que transmitem ou recebem o ficheiro. A fim de assegurar a compatibilidade entre os serviços dactiloscópicos em comunicação, é necessário que o registo apenas contenha os campos adiante listados. Este documento especifica os campos que são obrigatórios e os que são facultativos e define também a estrutura de cada um dos campos.

4.1. Campos do registo lógico de tipo-2

4.1.1. Campo 2.001: comprimento de registo lógico (LEN — Logical Record Length)

Este campo obrigatório indica o comprimento do registo de tipo-2 e especifica o número total de bytes, incluindo todos os caracteres de todos os campos, bem como os separadores de informação.

4.1.2. Campo 2.002: carácter designador de imagem (IDC — Image Designation Character)

O IDC contido neste campo obrigatório é uma representação ASCII do IDC definido no campo conteúdo do ficheiro (CNT) do registo de tipo-1 (campo 1.003).

4.1.3. Campo 2.003: informação do sistema (SYS — System Information)

Este campo é obrigatório e contém 4 bytes que indicam a versão da INT-I aplicada por este registo específico de tipo-2.

Os primeiros dois bytes designam o número da versão principal, os dois seguintes, o número da revisão de importância secundária. Por exemplo, esta aplicação baseia-se na INT-I versão 4, revisão 22, e será portanto representada por «0422».

4.1.4. Campo 2.007: número de processo (CNO — Case number)

Trata-se de um número atribuído pelo serviço dactiloscópico local a um conjunto de latentes detectado no local de um crime. É adoptado o seguinte formado: CC/número,

em que CC é o código de país da Interpol, com dois caracteres alfanuméricos, e o número segue as directrizes locais adequadas, podendo comportar até um máximo de 32 caracteres alfanuméricos.

Este campo permite que o sistema identifique as imagens latentes associadas a um determinado crime.

4.1.5. Campo 2.008: número de sequência (SQN)

Este número designa cada sequência de imagens latentes num processo. Pode ter no máximo quatro algarismos. Uma sequência é composta de uma imagem latente ou uma série de imagens latentes, que são agrupadas para efeitos de arquivagem e/ou busca. Esta definição implica que mesmo as imagens latentes isoladas terão de receber um número de sequência.

Este campo pode ser incluído juntamente com o MID (Campo 2.009) para identificar uma determinada imagem latente numa sequência.

4.1.6. Campo 2.009: identificador de imagem latente (MID)

Este campo especifica uma determinada imagem latente numa sequência. O valor é uma única letra ou duas letras, sendo atribuída «A» à primeira latente, «B» à segunda e assim por diante até ao limite de «ZZ». Este campo é utilizado de forma análoga ao número de sequência de imagem latente referido acima para SQN (Campo 2.008).

4.1.7. Campo 2.010: número de referência criminal (CRN — Criminal Reference Number)

Trata-se de um número de referência único atribuído por um serviço nacional a uma pessoa acusada pela primeira vez de cometer uma infracção. Em cada país, ninguém tem mais de um CRN nem partilha esse número com nenhuma outra pessoa. Todavia, a mesma pessoa pode ter números de referência criminal em vários países que poderão ser distinguidos graças ao código de país.

É adoptado o seguinte formato para o campo CRN: CC/número,

em que CC é o código de país definido na ISSO 3166, com dois caracteres alfanuméricos, e o número segue as directrizes do serviços emitente, podendo comportar até um máximo de 32 caracteres alfanuméricos.

Para transacções no âmbito da Decisão 2008/615/JAI, este campo será utilizado para o número de referência criminal do serviço originador relacionado com as imagens nos registos de tipo-4 ou de tipo-15.

4.1.8. Campo 2.012: outro número de identificação (MN1)

Este campo contém o CRN (campo 2.010) transmitido numa transacção CPS ou PMS não antecedido do código do país.

4.1.9. Campo 2.013: outro número de identificação (MN2)

Este campo contém o CRN (campo 2.007) transmitido numa transacção MPS ou MMS não antecedido do código do país.

4.1.10. Campo 2.014: outro número de identificação (MN3)

Este campo contém o SQN (campo 2.008) transmitido numa transacção MPS ou MMS.

4.1.11. Campo 2.015: outro número de identificação misto (MN4)

Este campo contém o MID (campo 2.009) transmitido numa transacção MPS ou MMS.

4.1.12. Campo 2.063: informações complementares (INF)

Nas transacções de resposta SER a um pedido PMS, este campo incluirá informações sobre o dedo que está na origem do eventual acerto. O campo tem o seguinte formato:

NN, sendo NN o código de dois algarismos da posição dactilar definida no quadro 5.

Nos restantes casos, este campo é facultativo. É composto por até 32 caracteres alfanuméricos e pode dar informações suplementares sobre o pedido.

4.1.13. Campo 2.064: lista de respostas (RLS — Respondents List)

Este campo comporta pelo menos dois subcampos. O primeiro descreve o tipo de busca mediante as mnemónicas de três letras que indicam o tipo de transacção em TOT (campo 1.004). O segundo contém uma única letra. «I» para assinalar um acerto e «N» para indicar a ausência de concordância (não acerto). O terceiro subcampo inclui o identificador de sequência do resultado do candidato e o número total de candidatos separado por uma barra. Se existirem múltiplos candidatos, haverá múltiplas mensagens.

Na eventualidade de um acerto, o quarto subcampo conterá o resultado com até seis algarismos. Se o acerto tiver sido verificado é atribuído o valor de «999999» a este subcampo.

Exemplo: «CPS{RS}I{RS}001/001{RS}999999{GS}»

Se o AFIS remoto não atribuir nenhum resultado, deve ser utilizado um zero no ponto adequado.

4.1.14. Campo 2.074: Campo relativo ao estatuto/mensagem de erro (ERM)

Este campo contém mensagens de erro geradas nas transacções e que serão reenviadas ao requerente numa transacção de erro.

Quadro 3: Mensagens de erro

Numeric Code (1-3) Meaning (5-128) 003 ERROR: UNAUTHORISED ACCESS 101 Mandatory field missing 102 Invalid record type 103 Undefined field 104 Exceed the maximum occurrence 105 Invalid number of subfields 106 Field length too short 107 Field length too long 108 Field is not a number as expected 109 Field number value too small 110 Field number value too big 111 Invalid character 112 Invalid date 115 Invalid item value 116 Invalid type of transaction 117 Invalid record data 201 ERROR: INVALID TCN 501 ERROR: INSUFFICIENT FINGERPRINT QUALITY 502 ERROR: MISSING FINGERPRINTS 503 ERROR: FINGERPRINT SEQUENCE CHECK FAILED 999 ERROR: ANY OTHER ERROR. FOR FURTHER DETAILS CALL DESTINATION AGENCY.

Mensagens de erro com códigos de 100 a 199:

Estas mensagens de erro estão relacionadas com a validação dos registos ANSI/NIST e são definidas do seguinte modo:

<código de erro 1>: IDC <idc_número 1> CAMPO <identificador de campo 1> <texto dinâmico 1> LF

<código de erro 2>: IDC <idc_número 2> CAMPO <identificador de campo 2> <texto dinâmico 2>…

em que:

— o código de erro indica uma razão específica (ver quadro 3)

— o identificador de campo é o número de campo ANSI/NIST do campo errado (p.ex: 1.001, 2.001, ...) no formato <tipo de registo>.identificador de campo>.identificador de subcampo>

— o texto dinâmico é uma descrição dinâmica mais pormenorizada do erro

— LF é um espaço que separa erros caso sejam encontrados vários erros

— para o registo de tipo-1, o IDC é definido como «-1»

Exemplo:

201: IDC –1 CAMPO 1.009 CARACTER DE CONTROLO ERRADO {LF} 115: IDC 0 CAMPO 2.003 SISTEMA DE INFORMAÇÃO INVÁLIDO

Este campo é obrigatório nas transacções de erro.

4.1.15. Campo 2.320: número de candidatos pretendido (ENC)

Este campo contém o número máximo de candidatos para verificação pretendido pelo serviço requerente. O valor do ENC não pode exceder os valores definidos no quadro 11.

5. Registo lógico de tipo-4: imagens dactiloscópicas de alta resolução em escala de cinzentos

Convém ter presente que os registos do tipo-4 têm sobretudo carácter binário e não ASCII. Por conseguinte, cada campo ocupa uma posição específica no registo, o que implica que todos os campos são obrigatórios.

A norma permite especificar no registo tanto a dimensão da imagem como a resolução. Os registos lógicos do tipo-4 devem conter dados de imagens dactiloscópicas que são transmitidas a uma resolução nominal de píxeis de 500 a 520 ppp. A taxa preferida para novas aplicações é uma densidade de 500 píxeis por polegada ou 19,68 píxeis por mm. 500 píxeis por polegada é a densidade especificada pela INT-I, embora sistemas semelhantes possam comunicar entre si a uma taxa diferente desde que se situe dentro do limite de 500 a 520 píxeis por polegada.

5.1. Campos do registo lógico de tipo-4

5.1.1. Campo 4.001: comprimento de registo lógico (LEN — Logical Record Length)

Este campo de quatro bytes indica o comprimento deste registo de tipo-4 e especifica o número total de bytes, incluindo todos os bytes de todos os campos contidos no registo.

5.1.2. Campo 4.002: carácter de designação da imagem (IDC — Image Designation Character)

Trata-se da representação binária do byte do número IDC indicado no ficheiro do cabeçalho.

5.1.3. Campo 4.003: tipo de impressão (IMP)

O tipo de impressão é um campo de um byte que ocupa o sexto byte do registo.

Quadro 4: Tipo de impressão digital

Code Description 0 Live-scan of plain fingerprint 1 Live-scan of rolled fingerprint 2 Non-live scan impression of plain fingerprint captured from paper 3 Non-live scan impression of rolled fingerprint captured from paper 4 Latent impression captured directly 5 Latent tracing 6 Latent photo 7 Latent lift 8 Swipe 9 Unknown

5.1.4. Campo 4.004: posição dactilar (FGP — Finger Position)

Este campo de comprimento fixo de 6 bytes ocupa as posições do sétimo ao décimo segundo byte de um registo do tipo-4. Contém as posições possíveis dos dedos com início no byte mais à esquerda (sétimo byte do registo). A posição dactilar conhecida ou mais provável é indicada de acordo com o quadro 5. Podem ser indicadas até cinco dedos suplementares, introduzindo as posições dos outros dedos nos cinco bytes restantes e utilizando o mesmo formato. Se forem utilizadas menos do que cinco referências de posições dactilares, os bytes não utilizados devem ser preenchidos com o binário 255. Para indicar todas as posições dactilares utiliza-se o código 0, que corresponde a «desconhecido».

Quadro 5: Código da posição dactilar e dimensão máxima

Finger position Finger code Width (mm) Length (mm) Unknown 0 40,0 40,0 Right thumb 1 45,0 40,0 Right index finger 2 40,0 40,0 Right middle finger 3 40,0 40,0 Right ring finger 4 40,0 40,0 Right little finger 5 33,0 40,0 Left thumb 6 45,0 40,0 Left index finger 7 40,0 40,0 Left middle finger 8 40,0 40,0 Left ring finger 9 40,0 40,0 Left little finger 10 33,0 40,0 Plain right thumb 11 30,0 55,0 Plain left thumb 12 30,0 55,0 Plain right four fingers 13 70,0 65,0 Plain left four fingers 14 70,0 65,0

Para imagens latentes encontradas no local de um crime, devem ser utilizados apenas os códigos de 0 a 10.

5.1.5. Campo 4.005: resolução da imagem de varrimento (ISR — Image Scanning Resolution)

Este campo de um byte ocupa o décimo terceiro byte de um registo do tipo-4. O valor «0» indica que a imagem foi captada com a resolução preferida de 19,68 píxeis/mm (500 píxeis por polegada). O valor «1» indica que a imagem foi captada com uma resolução diferente especificada no registo de tipo-1.

5.1.6. Campo 4.006: comprimento horizontal da linha (HLL — Horizontal Line Length)

Este campo ocupa os bytes 14 e 15 no registo do tipo-4. Indica o número de píxeis contidos em cada linha digitalizada. O primeiro byte é o mais importante.

5.1.7. Campo 4.007: comprimento vertical da linha (HLL — Vertical Line Length)

Este campo regista nos bytes 16 e 17 o número de linhas digitalizadas presentes na imagem. O primeiro byte é o mais importante.

5.1.8. Campo 4.008: algoritmo de compressão em escala de cinzentos (GCA — Gray-scale Compression Algorithm)

Este campo de um byte indica o algoritmo de compressão em escala de cinzentos utilizado para codificar os dados da imagem. Para efeitos da presente aplicação, o código 1 indica que foi utilizada a compressão WSQ (apêndice 7).

5.1.9. Campo 4.009: a imagem

Este campo contém um fluxo de bytes que representa a imagem. A sua estrutura dependerá obviamente do algoritmo de compressão que for utilizado.

6. Registo lógico de tipo-9: registo de minúcias

Os registos do tipo-9 conterão o texto ASCII que descreve as minúcias e informações conexas codificadas a partir de uma imagem latente. Para transacções de busca de latentes, o ficheiro pode conter um número indeterminado de registos de tipo-9, cada qual com uma visão ou imagem latente diferente.

6.1. Extracção de minúcias

6.1.1. Identificação do tipo de minúcia

Esta norma define os três números que identificam o tipo de minúcia. O quadro 6 enumera estes tipos. A terminação das cristas tem a designação de tipo 1. A bifurcação tem a designação de tipo 2. Se as minúcias não puderem ser classificadas claramente num dos dois tipos acima referidos, receberão a designação «outro», tipo 0.

Quadro 6: Tipos de minúcias

Type Description 0 Other 1 Ridge ending 2 Bifurcation

6.1.2. Posição e tipo de minúcias

Para que os templates obedeçam aos requisitos da secção 5 da norma ANSI INCITS 378-2004, deve ser utilizado o seguinte método, que reforça a actual norma INCITS 378-2004, para determinar a posição (localização e orientação) de cada minúcia.

A posição ou localização de uma minúcia que representa uma terminação de crista será o ponto de bifurcação do esqueleto medial da zona do vale imediatamente à frente dessa terminação. Se as três pernas da zona do vale forem esqueletizadas para a largura de um píxel, o ponto de intersecção é a localização da minúcia. Do mesmo modo, a localização de uma minúcia constituída por uma bifurcação será o ponto de bifurcação do esqueleto medial da crista. Se as três pernas da crista forem esqueletizadas para a largura de um pixel, o respectivo ponto de intersecção é a localização da minúcia.

Quando todas as terminações de cristas tiverem sido convertidas em bifurcações, todas as minúcias da imagem dactiloscópica são representadas como bifurcações. As coordenadas X e Y do pixel da intersecção das três pernas de cada minúcia podem ser formatadas directamente. A determinação da orientação da minúcia pode ser deduzida de cada bifurcação esqueletizada. As três pernas de cada bifurcação esqueletizada devem ser analisadas e a terminação de cada perna deve ser determinada. A figura 6.1.2 ilustra os três métodos utilizados para determinar a terminação de uma perna com base numa resolução de varrimento de 500 ppp.

A terminação é determinada de acordo com o que vem primeiro. A contagem dos píxeis é feita com uma resolução de varrimento de 500 ppp. Resoluções de varrimento diferentes implicariam contagens diferentes.

— Uma distância de .064" (o 32.o pixel)

— A terminação da perna do esqueleto entre uma distância de .02" e .064" (do 10.o ao 32.o píxeis); não se utilizam pernas mais curtas

— Uma segunda bifurcação é encontrada numa distância de .064" (antes do 32.o píxel)

Figura 6.1.2

O ângulo das minúcias é determinado colocando três raios virtuais com início no ponto de bifurcação até à terminação de cada perna. O ângulo mais pequeno dos três ângulos formados pelos raio é cortado ao meio para indicar a orientação das minúcias.

6.1.3. Sistema de coordenadas

As minúcias de uma impressão digital devem ser determinadas num sistema de coordenadas cartesiano. A localização das minúcias será representada pelas respectivas coordenadas x e y. A origem do sistema de coordenadas será o canto superior esquerdo da imagem original com os eixos x e y que se estendem respectivamente para a esquerda e para baixo. As coordenadas x e y de uma minúcia serão representadas em unidades píxel a partir da origem. Convém notar que a localização da origem e das unidades de medidas não é compatível com a convenção utilizada nas definições do tipo-9 na norma ANSI/NIST-ITL 1-2000.

6.1.4. Orientação das minúcias

Os ângulos são expressos num formato matemático normalizado, com zero graus à direita e o aumento do ângulo orientado no sentido contrário ao dos ponteiros do relógio. Nas terminações de crista, os ângulos registados apontam no sentido para trás ao longo da crista e nas bifurcações no sentido do vale. Esta convenção está diametralmente oposta à convenção de ângulo descrita nas definições do tipo-9 na norma ANSI/NIST-ITL 1-2000.

6.2. Campos do registo lógico de tipo-9 em formato INCITS-378

Todos os campos do tipo-9 devem ser registados como texto ASCII. Neste registo de campo etiquetado não são permitidos campos binários.

6.2.1. Campo 9.001: comprimento de registo lógico (LEN — Logical Record Length)

Este campo ASCII obrigatório deve conter o comprimento do registo lógico que especifica o número total de bytes, incluindo cada um dos caracteres de todos os campos contidos no registo.

6.2.2. Campo 9.002: carácter de designação da imagem (IDC — Image Designation Character)

Este campo obrigatório de dois bytes destina-se à identificação e localização dos dados referentes às minúcias. O IDC contido neste campo obrigatório deve corresponder ao IDC encontrado no campo do conteúdo do registo de tipo-1.

6.2.3. Campo 9.003: tipo de impressão (IMP)

Este campo obrigatório de um byte destina-se a descrever a forma como a informação relativa à imagem dactiloscópica foi obtida. O valor ASCII do código adequado seleccionado do quadro 4 deve ser introduzido neste campo para indicar o tipo de impressão.

6.2.4. Campo 9.004: formato das minúcias (FMT)

Este campo conterá a letra «U», que indica que as minúcias estão formatadas de acordo com a norma M1-378. Embora a informação possa ser codificada de acordo com a norma M1-378, todos os campos de dados do registo do tipo-9 devem continuar a ser campos de texto ASCII.

6.2.5. Campo 9.126: informação CBEFF

Este campo deve conter três elementos de informação. O primeiro conterá o valor «27» (0x1B), ou seja, a identificação do proprietário do formato CBEFF atribuída pela Associação Internacional da Indústria Biométrica (IBIA) ao Comité Técnico M1 do INCITS. O caracter <US> separa este elemento do tipo de formato CBEFF que tem o valor de «513» (0x0201) para indicar que este registo apenas contém os dados relativos à localização e à orientação angular sem informações de bloco de dados estendido. O separador <US> separa este elemento do identificador de produto (PID) CBEFF que identifica o «proprietário» do equipamento de codificação. Este valor é estabelecido pelo vendedor e pode ser obtido do sítio internet da IBIA (www.ibia.org) a pedido.

6.2.6. Campo 9.127: identificação do equipamento de captação

Este campo conterá dois elementos de informação separados pelo carácter <US>. O primeiro com a menção «APPF» se o equipamento utilizado para captar a imagem foi certificado de acordo com o Apêndice F (IAFIS — Image Quality Specification, de 29 de Janeiro de 1999) do CJIS-RS-0010, Federal Bureau of Investigation ’ s Electronic Fingerprint Transmission Specification. Se o equipamento não estiver conforme o campo ostentará a menção «NONE» (nada). O segundo elemento de informação conterá o identificador do equipamento de captação que é um número de produto atribuído ao vendedor do equipamento. O valor «0» indica a falta do identificador de equipamento.

6.2.7. Campo 9.128: comprimento horizontal da linha (HLL — Horizontal Line Length)

Este campo ASCI obrigatório conterá o número de píxeis numa linha horizontal da imagem transmitida. O comprimento horizontal máximo está limitado a 65 534 píxeis.

6.2.8. Campo 9.129: comprimento vertical da linha (HLL — Vertical Line Length)

Este campo ASCI obrigatório conterá o número de linhas horizontais da imagem transmitida. O comprimento vertical máximo está limitado a 65 534 píxeis.

6.2.9. Campo 9.130: unidades de escala (SLC — Scale units)

Este campo ASCII obrigatório indica as unidades utilizadas para descrever a frequência de captação da imagem (densidade de píxeis). O valor «1» neste campo indica o número de píxeis por polegada e o valor «2» o número de píxeis por centímetro. O valor «0» neste campo indica a ausência de escala. Nesse caso, o quociente de HPS/VPS indica o rácio do aspecto do pixel.

6.2.10. Campo 9.131: escala horizontal de píxeis (HPS — Horizontal pixel scale)

Este campo ASCII obrigatório deve conter a densidade total de píxeis na horizontal desde que o campo SLC ostente o valor «1» ou «2». Caso contrário, indica o componente horizontal do rácio do aspecto do pixel.

6.2.11. Campo 9.132: escala vertical de píxeis (VPS — Vertical pixel scale)

Este campo ASCII obrigatório deve conter a densidade total de píxeis na vertical desde que o campo SLC ostente o valor «1» ou «2». Caso contrário, indica o componente vertical do rácio do aspecto do pixel.

6.2.12. Campo 9.133: imagem dactilar

Este campo obrigatório indica o número da imagem do dedo correspondente aos dados deste registo. O número de imagem começa por «0» e vai de um a «15».

6.2.13. Campo 9.134: posição dactilar (FGP — Finger position)

Este campo deve indicar o código que identifica a posição dactilar que está na base da informação constante deste registo do tipo-9. Para indicar a posição dactilar ou palmar, deve ser utilizado um código de 1 a 10 do quadro 5 ou o código palmar adequado do quadro 10.

6.2.14. Campo 9.135: qualidade digital (Finger quality)

Este campo indica a qualidade geral dos dados relativos às minúcias digitais e os valores variam entre 0 e 100. Este número corresponde à avaliação geral da qualidade do registo digital e representa a qualidade da imagem original, da extracção das minúcias e eventuais operações suplementares que possam afectar o registo das minúcias.

6.2.15. Campo 9.136: número de minúcias

Este campo obrigatório contém a contagem do número de minúcias constantes deste registo lógico.

6.2.16. Campo 9.137: dados relativos às minúcias digitais (Finger minutiæ data)

Este campo obrigatório contém seis elementos de informação separados pelo carácter <US>. Compõe-se de vários subcampos, cada um dos quais contém os pormenores de minúcias individuais. O número total de subcampos deve corresponder à contagem indicada no campo 136. O primeiro elemento é constituído pelo número do índice das minúcias que começa em «1» e aumenta um valor para cada minúcia suplementar na impressão digital. Os segundos e terceiros elementos são as coordenadas «x» e «y» da minúcia expressas em unidades de píxeis. O quarto elemento de informação indica o ângulo das minúcias expresso em unidades de dois graus. Este valor deve ser um valor não negativo entre 0 e 179. O quinto elemento de informação identifica o tipo de minúcia. O valor «0» representa minúcias do tipo «OUTRAS», o valor «1» uma terminação de crista e o valor «2» uma bifurcação de crista. O sexto elemento indica a qualidade de cada minúcia. A variação máxima e mínima deste valor corresponde a 1 e 100, respectivamente. O valor «0» indica a ausência de valor de qualidade. Os subcampos devem ser separados com separadores <RS>.

6.2.17. Campo 9.138: informação relativa à contagem das cristas (Ridge count information)

Este campo é composto por uma série de subcampos, cada um dos quais contém três elementos de informação. O primeiro no primeiro campo indica o método de extracção da contagem de cristas. Um valor «0» indica que o método de extracção de contagem de cristas e a sua ordem no registo não devem ser tidos em conta. O valor «1» indica que, para cada ponto central de minúcia, os dados relativos à contagem de cristas foram extraídos até à minúcia mais próxima em quatro quadrantes e as contagens de cristas de cada centro de minúcia são agrupadas. O valor «2» indica que, para cada ponto central de minúcia, os dados relativos à contagem de cristas foram extraídos até à minúcia mais próxima em oito octantes e as contagens de cristas de cada centro de minúcia são agrupadas. Os restantes dois elementos do primeiro subcampo devem ambos ostentar o valor «0». Estes elementos devem ser separados pelo carácter <US>. Os subcampos seguintes contêm o número de índice do centro das minúcias como primeiro elemento, seguido do número de índice da minúcia adjacente e, por último, o número de cristas atravessadas. Os subcampos devem ser separados pelo carácter <US>.

6.2.18. Campo 9.139: informação sobre o ponto de referência (Core information)

Este campo contém um subcampo para cada ponto de referência presente na imagem original. Cada subcampo contém três elementos de informação. Os primeiros dois indicam as coordenadas «x» e «y» em unidades de píxeis. O terceiro elemento de informação indica o ângulo do pon