À te lire (entre autre du titre), tu sembles penser qu'il y a forcément un XOR entre une telle protection et la liberté. C'est faux.
On peut avoir un SE (moi je le connais sous le nom de Secure Element, mais Secure Enclave signifie la même chose) libre.
Pour un modèle simplifié, on peut imaginer un SE avec ce comportement:
- Il génère/enregistre en mémoire sécurisée (que seul lui peut lire/écrire de par sa conception dans le silicium), un jeu de clef RSA
- L'utilisateur veut chiffrer sa tablette avec le PIN 0000. Le système demande au SE de signer le message 0000 avec sa clef privée. Ce message signé devient alors la clef de chiffrement AES du stockage
- Lorsque l'utilisateur veut déchiffrer sa tablette, il doit demander au SE de signer le PIN 0000. Il peut s'autodétruire au bout de 10 essais.
- On peut flasher le SE comme on veut, mais le SE précédent efface la clef RSA lorsqu'on flashe le SE
Avec ce comportement, la sécurité est garantie, alors que le système est libre!
Cette implémentation est possible sur la plupart des ARM grâce au Trustzone (il faut que la plateforme ne verrouille pas le trustzone pour elle-même, donc exit les Qualcomm par exemple).
Il me semble que Chrome OS fait de même avec une puce dédiée, dont le code source est libre, mais j'en suis pas sûr.
Le comportement recommandé par Google sur les téléphones depuis Android M est voisin:
Pour le kernel, le système accepte de booter n'importe quoi, mais la clef publique qui a servi à signer le kernel est envoyé au trustzone. Si la clef a changé, le trustzone efface ses clefs.
Aussi, Google/Android fournit un SE libre basé sur Trustzone d'ARM https://source.android.com/security/trusty/index.html
Donc il est libre, n'empêche pas d'utiliser d'autres systèmes que ceux officiels, tout en gardant la sécurité d'inviolabilité des données. Néanmoins, à ma connaissance, il n'est pas possible d'en flasher un compilé soit-même.
# Pas de dilemme
Posté par Ph Husson (site web personnel) . En réponse au journal Dilemme entre vie privée et contrôle de sa machine. Évalué à 8.
À te lire (entre autre du titre), tu sembles penser qu'il y a forcément un XOR entre une telle protection et la liberté. C'est faux.
On peut avoir un SE (moi je le connais sous le nom de Secure Element, mais Secure Enclave signifie la même chose) libre.
Pour un modèle simplifié, on peut imaginer un SE avec ce comportement:
- Il génère/enregistre en mémoire sécurisée (que seul lui peut lire/écrire de par sa conception dans le silicium), un jeu de clef RSA
- L'utilisateur veut chiffrer sa tablette avec le PIN 0000. Le système demande au SE de signer le message 0000 avec sa clef privée. Ce message signé devient alors la clef de chiffrement AES du stockage
- Lorsque l'utilisateur veut déchiffrer sa tablette, il doit demander au SE de signer le PIN 0000. Il peut s'autodétruire au bout de 10 essais.
- On peut flasher le SE comme on veut, mais le SE précédent efface la clef RSA lorsqu'on flashe le SE
Avec ce comportement, la sécurité est garantie, alors que le système est libre!
Cette implémentation est possible sur la plupart des ARM grâce au Trustzone (il faut que la plateforme ne verrouille pas le trustzone pour elle-même, donc exit les Qualcomm par exemple).
Il me semble que Chrome OS fait de même avec une puce dédiée, dont le code source est libre, mais j'en suis pas sûr.
Le comportement recommandé par Google sur les téléphones depuis Android M est voisin:
Pour le kernel, le système accepte de booter n'importe quoi, mais la clef publique qui a servi à signer le kernel est envoyé au trustzone. Si la clef a changé, le trustzone efface ses clefs.
Aussi, Google/Android fournit un SE libre basé sur Trustzone d'ARM https://source.android.com/security/trusty/index.html
Donc il est libre, n'empêche pas d'utiliser d'autres systèmes que ceux officiels, tout en gardant la sécurité d'inviolabilité des données. Néanmoins, à ma connaissance, il n'est pas possible d'en flasher un compilé soit-même.