[cmNOG] Règlementation sur l'utilisation des certificats PKI et TLS

Dim 12 Avr 19:30:34 UTC 2020

Mes remarques en dessous.

J'espère que vous prenez en compte que lorsqu'on parle de signature électronique ici, c'est en fonction de la couche du modèle TCP/IP et du protocole dont on parle. Je le dis parce que le sentiment que j'ai est qu'on se focalise beaucoup sur TLS mais en réalité il y a plusieurs autres protocoles et couches. Bien sur je peux me tromper.

En fait en général on a deux grande familles de certificat a l’ANTIC

*         Les certificats utilisateurs : Qui te permet de faire les opérations de signatures ou chiffrement à travers par exemple les applications de messagerie électronique (S/MIME), soumission a un marché public il te faut un certificat http://www.marchespublics.cm, payer les cotisations CNPS de tes employés (Bientôt opérationnel )

*         Les certificats serveurs : connu le nom de SSL / TLS. Ils existe plusieurs variantes. Il est généralement utilisé pour la sécurisation des serveurs web  HTTP -> HTTPS

TLS peut aussi être lié aux noms de domaine à l'aide des extensions de sécurité du système de noms de domaine DNSSEC.

Les certificats utilisateurs et les certificats serveurs (TLS) garantissent tous les éléments suivant : Confidentialité, l'intégrité, l'authentification et la non répudiation. Par conséquent tu peux faire la signature ou le chiffrement avec les deux types de certificats

Les certificats auxquels tu fais reférence plus haut concernent des équipements électroniques. Mais ça ne concerne pas le chemin parcouru et ni les propriétés issues de la route donnée.

Pas seulement les équipements électroniques, mais aussi les serveurs, équipements réseaux de routage, équipements mobile embarques…

En fait pour qu’un certificat existe il faut bien le générer à travers une infrastructure PKI ou autre, alors de ce point la Loi dit si vous générer des certificats quelqu’en soit l’infrastructure matériel ou logiciel utilisé vous devez déclarer et obtenir une autorisation.

Le plus important ici est de savoir que des qu’il ya usage des certificats (Y compris dans les tables de routage de l’operateur ) il se doit de declarer cela.

Certes, il y a une PKI derrière mais je le répète, le problème à résoudre n'est pas le même. Par contre vous gagneriez à intégrer et à encourager les détenteurs de ressources IP au Cameroun à générer des certificats pour les annonces de leurs préfixes (les ROAs[3]).

Oui effectivement ils peuvent générer des certificats pour les annonces de leurs préfixes.

Il faut comprendre le bien fondé de cela. Pour l’Etat le fait de vous obliger a une obtenir une autorisation lui permet d’assurer le contrôle et la sécurité, pour l’operateur il est protégé en cas de litige en justice.

Les banques comprennent mieux le bien-fondé d’être accrédité par l’ANTIC car vu les opérations critiques de paiement qui se font en ligne.

Comme expliqué plus haut, on n'intègre pas à proprement parler RPKI dans un routeur.

RPKI est un ensemble de solutions techniques qui peuvent aider dans d'autres cadres (administratifs, légal) mais c'est à la base une solution technique qu'aucun gestionnaire de réseau ne devrait négliger.

Oui moi-même je suis d’accord. Mais seulement il faut comprendre le principe d’utilisation des certificats qui nécessite seulement une autorisation au préalable. En fin il faut savoir que L’ANTIC ICI EST UN TIERS DE CONFIANCE habilitée à effectuer des opérations de sécurité juridique d'authentification, de transmission et de stockage.

J'encourage donc l'ANTIC à se reposer sur ce système qui n'appartient pas à AFRINIC au passage mais à l'ensemble de la communauté Internet pour servir d'élements d'appui dans la résolution de problèmes comme celui présenté ci-dessus.

Oui je sais RPKI n’appartient pas a Afrinic c’était juste un exemple.

Merci pour la remarque sur l’utilisation mon certificat. 

J’encourage les autres a faire pareil.

https://www.comparitech.com/blog/information-security/pgp-encryption-gmail/

https://www.youtube.com/watch?v=4ba0K-DhoGo

-----Message d'origine-----
De : cmNOG [mailto:cmnog-bounces at lists.cmnog.cm] De la part de Willy Manga
Envoyé : dimanche 12 avril 2020 12:31
À : cmnog at lists.cmnog.cm
Objet : Re: [cmNOG] Règlementation sur l'utilisation des certificats PKI et TLS

Bonjour Brice,

merci beaucoup pour ce feedback que j'apprécie énormément et j'espère voir un peu plus souvent les avis des uns et des autres chacun suivant son secteur d'activité. C'est à travers les échanges et la communication qu'on peut améliorer l'existant.

Ceci dit, mon commentaire plus bas.

On 12/04/2020 12:11, Ndanga brice wrote:

> 1.      Qui peut émettre ou produire les certificats électronique ?

> [...]

> Le Cameroun ne fonctionne pas en vase clos, c’est le même principe 

> partout, y compris la France qu’on aime cité pour modèle qui se charge 

> à travers ANSSI de donner les autorisations aux entreprises.

> https://www.ssi.gouv.fr/administration/produits-certifies/ <https://www.ssi.gouv.fr/administration/produits-certifies/> 

En suivant ce que fait l'ANSSI, le périmètre de la certification dont il s'agit est, je cite:

"La certification peut concerner les solutions de cybersécurité et, plus largement, toutes les solutions numériques offrant des fonctionnalités de sécurité. Par exemple : les produits réseaux de type VPN ou pare-feu, les cartes à puces, les HSM, les TEE (Trusted Execution Environment), les produits pour systèmes industriels (automates programmables industriels, serveurs SCADA), etc.

"

Cela concerne des équipements réseaux mais chacun pris individuellement.

1.

https://www.ssi.gouv.fr/administration/produits-certifies/certification-faq/ <https://www.ssi.gouv.fr/administration/produits-certifies/certification-faq/> 

> 

> 

> Au Cameroun on distingues :

> 

> *  Root CA : qui est l’autorité de certification racine ( C-a-d se 

> charge de signer tous les certificats emis au Cameroun y compris ceux 

> du gouvernement et autres)

> 

> *  GovCA : qui est l’autorité de certification du gouvernement (C-a-d 

> se charge de signer uniquement les certificats du gouvernement )

> 

> *  ACA : qui est l’autorité de certification accréditée pour le 

> secteur privé.

Ca serait bien de documenter tout cela sur votre site web. Si c'est fait tant mieux.

> [...]

> L’accréditation permet aux certificats de mon entreprise d’avoir la 

> signature de l’autorité de certification racine du Cameroun. Cela veut 

> dire que en cas de litige les opérations ou transaction qui ont été 

> faites avec ce certificat pourront faire office de preuve numérique 

> devant la justice camerounaise. En revanche celui qui a un contentieux 

> en justice pour une opération faite avec un certificat non signé par 

> l’autorité racine du Cameroun, toutes les preuves numériques sur ces 

> opérations seront simplement rejetés.

A mon humble avis, vous gagneriez à faire reconnaitre votre PKI à un niveau sous-régional voire global. Cela facilitera la validation de votre AC par les différents équipements. Car j'imagine qu'il y a plusieurs validations (semi)manuelles qu'il faut opérer pour faire accepter votre AC par les équipements électroniques.

> En plus je dois savoir que si j’exerce des activités de certifications 

> et signatures électronique sans accréditations je m’expose à des sanctions.

J'espère que vous prenez en compte que lorsqu'on parle de signature électronique ici, c'est en fonction de la couche du modèle TCP/IP et du protocole dont on parle. Je le dis parce que le sentiment que j'ai est qu'on se focalise beaucoup sur TLS mais en réalité il y a plusieurs autres protocoles et couches. Bien sur je peux me tromper.

> 

> 3.     Comment faire pour permettre aux certificats d’une entreprise X basé

> à l’étranger d’être reconnus aux Cameroun en respectant la réglementation ?

J'aimerais attirer ton attention ici qu'il faut bien comprendre le problème qu'on veut résoudre. Par rapport à ce que tu dis plus bas il faut comprendre que l'écosystème RPKI  [2] s'occupe de donner des moyens pour sécuriser la table de routage Internet.

La table de routage Internet c'est un ensemble de routes, chacune avec plusieurs propriétés, permettant d'atteindre une destination en traversant un ou plusieurs numéros de système autonome.

Les certificats auxquels tu fais reférence plus haut concernent des équipements électroniques. Mais ça ne concerne pas le chemin parcouru et ni les propriétés issues de la route donnée.

Certes, il y a une PKI derrière mais je le répète, le problème à résoudre n'est pas le même. Par contre vous gagneriez à intégrer et à encourager les détenteurs de ressources IP au Cameroun à générer des certificats pour les annonces de leurs préfixes (les ROAs[3]).

Maintenant au niveau de l'ANTIC, (ou de tout gestionnaire réseaux

d'ailleurs) vous pourrez confirmer la validité[3] des certificats en installant un validateur dans votre réseau. Ce dernier se chargera de télécharger tous les certificats émis, non pas seulement par AFRINIC mais aussi ceux émis par les 4 autres RIR. Car, n'oubliez pas que les ressources IP que vous utilisez sont un bien collectif à l'échelle mondiale (faut le voir juste un peu comme l'air que nous respirons tous).

2. https://tools.ietf.org/html/rfc6480 <https://tools.ietf.org/html/rfc6480> 

3. https://tools.ietf.org/html/rfc6482 <https://tools.ietf.org/html/rfc6482> 

4. https://tools.ietf.org/html/rfc6483 <https://tools.ietf.org/html/rfc6483> 

> Les certificats de la Bicec et Afrinic pour etre reconnu au Cameroun 

>doivent  avoir des accords de reconnaissance mutuelle.

>[...]

Je vais vous présenter un exemple concret de problème que vient résoudre les ROAs. Je vais aussi le simplifier (je m'excuse auprès de mes collègues pour la simplification)

Considérons cette IPv4 : 41.204.76.226 (où pointe au moment de la rédaction www.antic.cm <http://www.antic.cm> ).

D'après les informations de la base whois d'AfRINIC [5]. Deux informations parmi d'autres:

- cette adresse figure dans le pool 41.204.76.128/25 (ligne 12)

- Ce pool est lui même intégré dans l'annonce du pool 41.204.64.0/19 (ligne 27)  faite par l'AS15964 (ligne 31).

Dans les tables de routage, en temps normal, n'importe quel gestionnaire réseau dans le monde (à tcholliré, campo, bangui, tokyo) doit voir dans ses routes que l'IP 41.204.76.226 a pour ASN d'origine le 15964.

Cette information, par défaut, moi routeur X je ne peux que lui faire une confiance aveugle. Car rien n'empêche à n'importe qui sur Internet au moment de la rédaction de mon mail, de dire que son ASN peut aussi être à l'origine de l'annonce du bloc 41.204.64.0/19 . Rien du tout [6].

Le problème que vient donc aider à résoudre RPKI et précisément les ROAs est de permettre à n'importe quel gestionnaire réseau d'authentifier que le préfixe 41.204.64.0/19 peut être annoncé sur Internet par l'AS15964 et par personne d'autre.

J'espère que l'exemple est suffisamment clair quant au problème à résoudre ici.

J'encourage donc l'ANTIC à se reposer sur ce système qui n'appartient pas à AFRINIC au passage mais à l'ensemble de la communauté Internet pour servir d'élements d'appui dans la résolution de problèmes comme celui présenté ci-dessus.

Pour ceux qui voudrait avoir plus d'informations sur RPKI, je vous encourage à revoir ce webinaire [7]

5. http://paste.debian.net/1139894/ <http://paste.debian.net/1139894/> 

6. Et d'ailleurs en passant, l'ASN 15964 est en train d'annoncer des blocs réservés

7. https://youtu.be/RU7wQQZGi9U <https://youtu.be/RU7wQQZGi9U> 

> Je tiens encore à préciser que sur le plan fonctionnel RPKI de Afrinic 

> peut être intégrer dans les routeurs du Cameroun sans problème et 

> garantir la sécurité qu’il faut. Mais seulement si les opérateurs le 

> font sans se rassurer qu’il existe un accord de reconnaissance 

> mutuelle entre les deux parties, l’operateur qui le fait ne respecte 

> pas la réglementation. Ce le meme cas pour les certificats de la Bicec.

Comme expliqué plus haut, on n'intègre pas à proprement parler RPKI dans un routeur.

RPKI est un ensemble de solutions techniques qui peuvent aider dans d'autres cadres (administratifs, légal) mais c'est à la base une solution technique qu'aucun gestionnaire de réseau ne devrait négliger.

> Pour ce qui des accord mutuelle de reconnaissance, cela existe partout.

> Exemple en Europe : L’accord européen de reconnaissance mutuelle du 

> SOG-IS de 2010

> https://www.ssi.gouv.fr/administration/produits-certifies/cc/les-accor <https://www.ssi.gouv.fr/administration/produits-certifies/cc/les-accor> 

> ds-de-

> reconnaissance-mutuelle

OK.. ça serait bien de connaître les types d'accords qui existent aussi au niveau national et sous-régional.

> 

> Security Engineer Information Systems

> [...]

> My Fingerprint : 29BD ADD6 6527 91FF E531 CA4E 8684 D44C 2A81 6F4E

P.S: Sur le plan personnel, je t'encourage à utiliser ta clé pour signer tes mails. Vous avez toujours la mienne dans tous mes mails ;-)

Encore merci pour le partage :)

--

Willy Manga

@ongolaboy

https://ongola.blogspot.com/ <https://ongola.blogspot.com/> 

Security Engineer Information Systems
Tél : +237 699088538 / 678381047
Skype : ndanga.brice
My Public Key : PGPKey <https://keyserver.ubuntu.com/pks/lookup?op=get&search=0x5fc34cf5bfc29d74a9346c7df9047f7089314785> 
My Fingerprint : 5FC34CF5BFC29D74A9346C7DF9047F7089314785

-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <https://lists.cmnog.cm/pipermail/cmnog/attachments/20200412/fea0902a/attachment-0001.htm>
-------------- section suivante --------------
Une pièce jointe autre que texte a été nettoyée...
Nom: non disponible
Type: application/pgp-signature
Taille: 489 octets
Desc: non disponible
URL: <https://lists.cmnog.cm/pipermail/cmnog/attachments/20200412/fea0902a/attachment-0001.sig>