> For the complete documentation index, see [llms.txt](https://docs.caf.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.caf.io/sdk-lite/sdk-lite-english-pt-br/configuracao/android/security-checks.md).

# Verificações de segurança

## Contexto

O Face Liveness Lite protege o resultado de liveness com duas camadas independentes de verificações:

<table><thead><tr><th width="146.1328125">Camada</th><th width="101.234375">Onde é executada</th><th width="118.19921875">Quando é executada</th><th>O que você recebe quando bloqueia</th></tr></thead><tbody><tr><td>Verificações de dispositivo da Certta</td><td>No dispositivo, no SDK</td><td>Antes e durante a captura</td><td><code>LivenessLiteEvent.Error</code> com o tipo <code>SECURITY_EXCEPTION</code>. Sem resposta assinada.</td></tr><tr><td>Verificações do iProov</td><td>Nos servidores do iProov</td><td>Enquanto a captura é processada</td><td><code>LivenessLiteEvent.Failure</code> com o tipo <code>DEVICE_ISSUE</code>, com uma resposta assinada.</td></tr></tbody></table>

As duas camadas sempre fazem parte do fluxo. As verificações de dispositivo da Certta podem ser desativadas com `enableSecurity`. As verificações do iProov não podem ser desativadas pelo app.

## Verificações de dispositivo da Certta

O SDK verifica o dispositivo antes e durante a captura para garantir que o resultado não foi adulterado. Se o dispositivo parecer comprometido, o SDK interrompe a captura e retorna um erro em vez de um resultado.

### **O que é verificado**

| Proteção              | O que detecta                                                                                                                |
| --------------------- | ---------------------------------------------------------------------------------------------------------------------------- |
| Detecção de root      | Dispositivos com root, o `su` binário, Magisk e Zygisk.                                                                      |
| Frameworks de hooking | Frida (biblioteca, porta do servidor, threads e arquivos), Xposed e LSPosed.                                                 |
| Integridade do código | Bibliotecas de hooking ou injeção carregadas no app, e funções do sistema redirecionadas ou corrigidas em tempo de execução. |
| Depuração             | Um depurador conectado ao app, um processo rastreando o app ou um app compilado como depurável.                              |
| Análise de tempo      | Tempo de execução que sugere um depurador ou rastreador de passos. Usado para confirmar outros achados, nunca isoladamente.  |

As verificações são fail-closed: se uma delas não puder ser executada, o SDK a trata como uma ameaça. Uma verificação com falha ou burlada nunca permite que a captura prossiga.

Qualquer achado bloqueia a captura. Não há nível de severidade que tenha permissão para continuar.

{% hint style="info" %}
Os emuladores não são bloqueados pelas verificações de dispositivo por si só. Um emulador só é bloqueado quando aciona uma das verificações acima, por exemplo quando a imagem do emulador tem root ou o app é uma build de depuração.
{% endhint %}

### **Como funciona**

1. **Antes da captura.** Quando você chama `startLiveness()`, o SDK verifica o dispositivo antes de abrir a câmera. Se uma ameaça for encontrada, a câmera nunca abre.
2. **Durante a captura.** Enquanto a captura está em andamento, o SDK verifica o dispositivo novamente a cada 2 segundos. Se surgir uma ameaça, por exemplo uma ferramenta de hooking conectada no meio da captura, a captura é interrompida imediatamente.
3. **No final.** Quando a execução termina, o monitoramento para.

As verificações também são executadas durante `prewarm()`. Uma ameaça encontrada ali não retorna um erro: o prewarm é ignorado, e `startLiveness()` executa as verificações novamente.

Depois que uma ameaça é encontrada em um dispositivo, o resultado é salvo no armazenamento privado do app e incluído em todas as verificações posteriores. O dispositivo permanece bloqueado até que os dados do app sejam apagados ou o app seja reinstalado.

### **Configuração**

| Parâmetro        | Tipo      | Padrão | Descrição                                                                         |
| ---------------- | --------- | ------ | --------------------------------------------------------------------------------- |
| `enableSecurity` | `Boolean` | `true` | Executa as verificações de dispositivo CAF antes e durante a captura de liveness. |

{% hint style="info" %}
Mantenha `enableSecurity` definido como `true` em produção. Desativá-lo remove a proteção contra dispositivos adulterados.
{% endhint %}

### **Quando uma ameaça é encontrada**

O SDK retorna um `LivenessLiteEvent.Error` com o tipo `SECURITY_EXCEPTION`. O `description` resume quantas ameaças foram encontradas, agrupadas por severidade:

```
Ameaça de segurança detectada durante o processo: ameaças de segurança detectadas: 1 crítica, 1 média
```

Tentar novamente no mesmo dispositivo retorna o mesmo erro, porque o achado é salvo até que os dados do app sejam apagados ou o app seja reinstalado. Mostre uma mensagem genérica e deixe o usuário tentar novamente, sem informar o que foi detectado. Se o erro continuar acontecendo, encaminhe o usuário para outro caminho de verificação. Veja [SECURITY\_EXCEPTION](/sdk-lite/sdk-lite-english-pt-br/tratamento-de-erros/android/error-handling.md#security_exception).

## Verificações do iProov

A captura é processada pelo iProov, que executa suas próprias verificações contra ataques de injeção digital, como fluxos de vídeo manipulados ou um app adulterado. Essas verificações são executadas nos servidores do iProov, então não podem ser burladas no dispositivo.

Quando essas verificações não são aprovadas, a captura ainda é processada e o SDK retorna uma `LivenessLiteEvent.Failure` com o tipo `DEVICE_ISSUE`, juntamente com uma resposta assinada. Valide-a no seu backend como qualquer outro resultado.

### **Ambientes do iProov**

O iProov executa suas verificações em um ambiente chamado provedor de serviço. Cada tipo de provedor de serviço aplica suas próprias regras:

| Tipo de provedor de serviço | Configuração de compilação | Modo de instalação                            | Testes de injeção |
| --------------------------- | -------------------------- | --------------------------------------------- | ----------------- |
| Desenvolvimento             | Qualquer build             | Qualquer instalação                           | Aprovado          |
| Produção                    | Build de release           | ADB                                           | Reprovado         |
| Produção                    | Build de release           | Instalação normal, APK ou loja de aplicativos | Aprovado          |
| Produção                    | Build de depuração         | ADB                                           | Reprovado         |
| Produção                    | Build de depuração         | Instalação normal, APK ou loja de aplicativos | Reprovado         |
| Teste                       | Build de release           | ADB                                           | Reprovado         |
| Teste                       | Build de release           | Instalação normal, APK ou loja de aplicativos | Aprovado          |
| Teste                       | Build de depuração         | ADB                                           | Reprovado         |
| Teste                       | Build de depuração         | Instalação normal, APK ou loja de aplicativos | Reprovado         |

Quando os testes de injeção falham, o SDK retorna uma `DEVICE_ISSUE` falha.

{% hint style="info" %}
Executar o app pelo Android Studio o instala por ADB. Em produção, uma execução iniciada dessa forma retorna `DEVICE_ISSUE` mesmo com uma build de release. Para testar o fluxo completo, instale uma build de release a partir de um arquivo APK ou da loja de aplicativos.
{% endhint %}

O ambiente do iProov usado pela sua conta é configurado pela Certta. Se você precisar de uma configuração diferente para testes, entre em contato com a equipe da sua conta na Certta.

### Testando Sua Integração

Por causa dessas duas camadas, uma build de depuração do Android Studio não consegue concluir uma captura de liveness em produção:

* Com `enableSecurity = true`, as verificações de dispositivo da Certta detectam o app depurável e retornam `SECURITY_EXCEPTION`.
* Com `enableSecurity = false`, a captura é executada, mas as verificações do iProov retornam uma `DEVICE_ISSUE` falha.

Para testar o fluxo completo, use uma build de release instalada a partir de um arquivo APK ou da loja de aplicativos, com `enableSecurity = true`.

{% hint style="warning" %}
Se um dispositivo de teste foi bloqueado pelas verificações de dispositivo da Certta antes, ele permanece bloqueado após você alterar a build. Limpe os dados do app ou reinstale o app.
{% endhint %}


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.caf.io/sdk-lite/sdk-lite-english-pt-br/configuracao/android/security-checks.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.