> 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/ios/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: | Camada | Onde é executada | O app pode desativá-lo? | Como isso chega ao seu app | | -------------------------------------------------------------- | --------------------------------------------------------- | ------------------------- | ----------------------------------------------------------------------------------------- | | [Verificações de dispositivo da Certta](#certta-device-checks) | No dispositivo, antes e durante a captura | Sim, com `enableSecurity` | `didFinishWithError(type: .securityException, description:)`, sem nenhum `signedResponse` | | [Verificações do iProov](#iproov-checks) | Nos servidores da iProov, enquanto a captura é processada | Não | `didFinishWithFailure(type:description:signedResponse:)`, com um `signedResponse` | Ambas as camadas fazem parte de toda captura. 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 e o ambiente do app para garantir que o resultado não foi adulterado. Se o ambiente parecer comprometido, o SDK para e retorna um erro em vez de um resultado. ### O que é verificado | Área | Exemplos | | --------------------------- | ------------------------------------------------------------------ | | Integridade do dispositivo | Um dispositivo com jailbreak | | Instrumentação e hooking | Ferramentas que injetam código no app ou interceptam suas chamadas | | Depuração | Ferramentas de depuração anexadas ao app | | Integridade do app e do SDK | Um binário do app modificado ou reassinado, ou um SDK com patch | Qualquer achado bloqueia a captura. Não há nível de severidade que tenha permissão para continuar. {% hint style="info" %} A captura só é executada em um dispositivo físico. O Simulador do iOS não é suportado. {% endhint %} ### Como funciona {% stepper %} {% step %} ## Antes da captura Quando você chama `startSDK(viewController:)`, o SDK verifica a permissão da câmera e então executa as verificações do dispositivo, antes de criar a sessão de liveness e abrir a câmera. Se uma ameaça for encontrada, a câmera nunca é aberta. {% endstep %} {% step %} ## Durante a captura Enquanto a captura está em andamento, o SDK verifica o dispositivo novamente periodicamente. Se surgir uma ameaça, por exemplo, uma ferramenta de hooking anexada no meio da captura, a captura é interrompida imediatamente. {% endstep %} {% step %} ## No final Quando a execução termina, com qualquer resultado, o monitoramento é interrompido. {% endstep %} {% endstepper %} `prewarm()` não executa as verificações do dispositivo. Elas sempre são executadas quando `startSDK` é chamado, tenha ou não a sessão sido pré-aquecida. O resultado não é salvo no dispositivo. Cada `startSDK` chamada executa as verificações novamente, então o mesmo ambiente retorna o mesmo resultado até que a condição que o acionou desapareça. ### Configuração `enableSecurity` é definido no construtor e o valor padrão é `true`: ```swift let sdk = CafFaceLivenessLiteSDK(enableSecurity: true) ``` | Cenário | `enableSecurity` | Efeito | | ------------------------------------------ | -------------------- | ----------------------------------------------------------------------------------------------------------------- | | Produção | `true` (recomendado) | As verificações do dispositivo são executadas e `securityException` podem ser retornadas | | QA manual e testes de aceitação | `true` (recomendado) | Mesmo comportamento que em produção, então os testes refletem o que os usuários recebem | | Testes automatizados de UI | `false` | As verificações do dispositivo não são executadas, então as ferramentas de teste não podem interromper a execução | | Qualquer build com `enableSecurity: false` | `false` | `securityException` nunca é retornado | O `ambiente` passado para `setup` (`.dev`, `.beta` ou `.prod`) não altera as verificações do dispositivo. Somente `enableSecurity` faz. {% hint style="warning" %} Mantenha `enableSecurity` definido como `true` em produção. Desativá-lo remove a proteção contra dispositivos comprometidos. {% endhint %} ### Quando uma ameaça é encontrada O SDK chama `didFinishWithError(type: .securityException, description:)`. Nenhuma captura é avaliada e nenhum `signedResponse` é retornado. O `description` é um texto técnico destinado aos seus logs. Não o analise nem o mostre ao usuário. Se precisar de ajuda com um caso, compartilhe-o com o suporte da Certta exatamente como está. Tentar novamente no mesmo ambiente retorna o mesmo erro até que a condição que o acionou desapareça. Não tente novamente automaticamente: * Exiba uma mensagem genérica, como "Não foi possível concluir a verificação. Tente novamente.", e permita que o usuário tente de novo. Não informe ao usuário o que foi detectado. * Se o erro continuar acontecendo, direcione o usuário para outro caminho de verificação, como outro dispositivo ou um canal assistido. Veja [Tratamento de Erros](/sdk-lite/sdk-lite-english-pt-br/tratamento-de-erros/ios/handling-errors.md) sobre como lidar com os outros tipos de erro. ## Verificações do iProov A captura é processada pela iProov, que executa suas próprias verificações contra ataques de apresentação, como fotos, telas ou máscaras, e contra ataques de injeção digital, como fluxos de vídeo manipulados ou um app adulterado. Essas verificações são executadas nos servidores da iProov, então não podem ser burladas no dispositivo. Quando essas verificações não passam, a captura ainda é processada e o SDK chama `didFinishWithFailure(type:description:signedResponse:)` com um `signedResponse`. Valide-o no seu backend como qualquer outro resultado. {% hint style="warning" %} Nunca decida o resultado de vivacidade no cliente. Seu backend valida o `signedResponse` e então recupera o resultado final com o `livenessAttemptId` que ele carrega. Veja [Configuração do backend](/sdk-lite/sdk-lite-english-pt-br/configuracao/backend/setup.md). {% endhint %} ### Códigos de feedback Quando uma captura não passa, a iProov retorna até três códigos de feedback. O SDK entrega o primeiro como o `parâmetro` de `didFinishWithFailure`, mapeado para o `CafFailureType` com o mesmo nome. Um código que o SDK não reconhece é retornado como `unknown`. A lista completa está em [Referência de resultado](/sdk-lite/sdk-lite-english-pt-br/configuracao/ios/result-reference.md). Os códigos de feedback são orientações para a próxima tentativa, não uma descrição do que foi detectado. O feedback relacionado ao dispositivo é deliberadamente genérico: descrever quais sinais são avaliados ajudaria os atacantes a se adaptar. `motionIssue` e `deviceIssue` costumam ser resolvidos pelo usuário na próxima tentativa, sem trocar de dispositivo. Para esses tipos: * Peça ao usuário para alinhar o rosto no oval e depois ficar imóvel. * Lembre o usuário de mover a cabeça, não o celular, para alinhar o rosto com o oval. * Sugira um local bem iluminado, sem reflexo no rosto. * Sugira tentar outro dispositivo apenas como último recurso, após várias tentativas. ### Erros da iProov Quando a iProov não consegue concluir a captura, o SDK mapeia o erro da iProov para um `CafErrorType` e chama `didFinishWithError(type:description:)`: | Erro da iProov | `CafErrorType` | Significado | | ------------------------ | ------------------------------- | ---------------------------------------------------------------------- | | `cameraPermissionDenied` | `cameraPermission` | O usuário negou o acesso à câmera | | `networkError` | `networkException` | A conexão falhou enquanto a captura estava sendo transmitida | | `serverError` | `serverException` | Ocorreu um erro no servidor, ou o token da captura não era mais válido | | `notSupported` | `unsupportedDevice` | O dispositivo não é compatível | | `captureAlreadyActive` | `captureAlreadyActiveException` | Outra captura já estava em andamento | | `userTimeout` | `userTimeoutException` | O usuário demorou demais para concluir a captura | | `unexpectedError` | `unexpectedErrorException` | Ocorreu um erro inesperado e irrecuperável | | Qualquer outro erro | `serverException` | Um erro não mapeado para um tipo específico | Veja [Tratamento de Erros](/sdk-lite/sdk-lite-english-pt-br/tratamento-de-erros/ios/handling-errors.md) sobre o que fazer com cada tipo. ### Ambientes do iProov A iProov executa suas verificações no ambiente configurado para sua conta. Esse ambiente é configurado pela Certta. Se precisar de uma configuração diferente para testes, entre em contato com a equipe da sua conta na Certta. ## Testando Sua Integração * Teste em um dispositivo físico. O Simulador do iOS não consegue executar a captura. * Mantenha `enableSecurity = true` em QA manual. Defina-o como `false` somente para testes automatizados de UI. * As verificações da iProov são executadas em toda captura, independentemente do tipo de build ou do valor de `enableSecurity`. * Para reproduzir o que seus usuários recebem, teste com uma build distribuída da mesma forma que em produção, como via TestFlight ou pela App Store. * Se as capturas de teste continuarem retornando `deviceIssue`, envie o `signedResponse` de cada tentativa, com a data e a hora, para a equipe da sua conta na Certta. --- # 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/ios/security-checks.md?ask=&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.