14.4.1. Concetti: fiducia, chiavi e formato dei file

Prima di qualsiasi comando, tre nozioni di base che valgono per ogni altra pagina di questa sezione.

14.4.1.1. Modelli di fiducia

Una connessione TLS può fornire tre livelli crescenti di garanzia:

  • Solo crittografia – il traffico è crittografato ma nessuna delle due parti dimostra la propria identità. Facile da configurare (nessuna validazione del certificato) ma vulnerabile a un attacco man-in-the-middle. Da usare solo per test locali.

  • Autenticazione del server – il client verifica il certificato del server rispetto a un certificato attendibile (il familiare modello HTTPS). La OpenMV Cam può agire sia come client (verificando un server remoto) sia come server (presentando il proprio certificato).

  • Autenticazione reciproca (mTLS) – entrambi gli estremi presentano e verificano i certificati. Si usa quando anche il server deve essere certo dell’identità del client.

14.4.1.2. Scelta del tipo di chiave

La build mbedTLS della camera supporta ECDSA sulle curve prime NIST/SEC e RSA. Ci sono tre modi pratici per creare una chiave; è consigliato ECDSA P-256 (prime256v1):

  • ECDSA P-256 (prime256v1) – circa 128 bit di sicurezza con una chiave a 256 bit. Chiavi e firme minuscole, e di gran lunga l’handshake più veloce tra le opzioni supportate su un Cortex-M (le operazioni a curva ellittica sono molto più economiche delle operazioni di chiave privata RSA). Supportato universalmente dai peer TLS. È il miglior equilibrio tra sicurezza, velocità, uso di RAM/flash e compatibilità su un dispositivo embedded, ed è per questo che qui è la scelta predefinita.

  • ECDSA P-384 (secp384r1) – circa 192 bit di sicurezza. Ancora a curva ellittica, quindi ragionevolmente efficiente, ma più grande e più lento di P-256 per un margine di sicurezza di cui i tipici deployment IoT non hanno bisogno. Da usare solo se un certificato a lunga durata o un requisito di conformità lo richiede.

  • RSA-2048 – circa 112 bit di sicurezza. Universalmente compatibile, anche con peer molto datati, ma le chiavi e i certificati RSA sono molto più grandi e le operazioni di chiave privata RSA (eseguite dalla parte che presenta il certificato) sono l’opzione più lenta e più avida di memoria su un microcontrollore. Da usare solo quando un peer non è in grado di usare ECDSA.

Nota

Le chiavi Ed25519 / Curve25519 non sono supportate. La build mbedTLS della OpenMV Cam non abilita EdDSA o Curve25519, quindi un certificato o una chiave Ed25519 non si caricherà o non completerà l’handshake. Usa una delle tre opzioni precedenti.

14.4.1.3. Formato dei file: usa DER

La build mbedTLS usata dalla OpenMV Cam non include il parsing PEM, quindi la camera legge certificati e chiavi solo in forma DER (la codifica binaria). La maggior parte degli strumenti emette per impostazione predefinita la forma PEM (testo base64), quindi ogni file destinato alla camera viene prima convertito in DER – ogni ricetta di questa sezione termina con quel passaggio di conversione. Avrai bisogno di:

  • Una chiave privata – tenuta segreta, usata dalla parte che presenta un certificato.

  • Un certificato – la parte pubblica, presentata all’altra parte durante l’handshake.

  • Un certificato CA / di fiducia – il certificato che la parte che verifica carica per decidere se il peer è attendibile. Per una configurazione self-signed questo è semplicemente il certificato del peer stesso.