Bon, pour on ne va pas se mentir, j’ai un peu dû me forcer pour lire le document du GROUPE DE TRAVAIL CYBERSÉCURITÉ du G7 (pour mémoire USA, Germanie, UK, France, Canada, Italie et Japon) , téléchargeable ici et publié le 3 septembre 2026.

Je n’en attendais rien de particulier, je n’ai donc pas été déçu. On y retrouve tous les poncifs habituels qui ne vont à mon avis pas motiver davantage grand monde. Mais au moins, si un jour (Q-day) ca merdoie, ils pourront dirent qu’ils avaient tenter de prévenir …

Donc, il n’y a pas à tortiller, la PQC, pour vivre sereinement notre cypto asymétrique… il faut y aller. Le doc s’intitule bien « A call to action » et se situe entre le prêche dominical et l’injonction étatique. Comply ! Sinon … fin du business, soon !

Au delà de l’introduction habituelle convenue sur le risque qu’apportera le CRQC (lire Cryptograpicaly Relevant Quantum Computer), le G7 tentera de faire pointer toute votre attention sur les 5 actions attendues :

• Raising awareness
• Developing national strategies
• Research and development
• Developing public-private partnerships
• Integrating PQC into cybersecurity requirements

La France, par l’intermédiaire de l’ANSSI, a fait déposer le document chez Outscale. Le truc rigolo, c’est que pour un doc censé promouvoir une dynamique, et contrairement à 70 % du trafic web actuel, le serveur ne supporte pas x25519MLKEM768.

Allez, faites ce que j’écris pas ce que je fais: Havest now, decrypt later, comme ils disent.

Et pour ce que ne dit pas le document, intéressant post de Brian C. d’ISN (bon, les boites de conseils qui surfent sur le FUD, on vous voit aussi :-)).

En revanche, PQC ou pas PQC, G€ ou peanuts, tant que vous ne réaliserez pas qu’un vol d’identité casse votre modèle de sécurité vous pourrez continuer à postuler à la DGFiP.

A major milestone has now been reached in the smartcard industry, marking a turning point in the race toward quantum-safe security.

https://www.thalesgroup.com/en/search/shift-post-quantum-cryptography-reshaping-digital-trust

Download the ABI Research Report to understand the certification milestone that is reshaping trust in digital identity, payments and government security.

=> fill in the form …

1/ Méthode « gros con »

=> T’as pas appris ça à Cesson ?

2 / Méthode Charlie aka la pédagogie inductive

=> Demande à Google

3 / Méthode hacking

On récupère quelques morceaux de bonne facture et on demande à chatGPT / GenIAl d’en faire une version pour sergent/chef et on fait la démonstration IRL.

Et bien sur dès le début on commence par mettre à jour son Wireshark.

https://tls13.xargs.org/#client-key-exchange-generation

Trouvé sur LinkedIn :

https://www.linkedin.com/posts/baswesterbaan_i-updated-pqspy-a-little-firefox-extension-share-7487861733542354945-cKFy/

I updated PQSpy, a little Firefox extension that shows you in a little icon whether the page you’re visiting is post-quantum encrypted ⚛️, or not ❌, or partially with a kind of pie chart.

Click the icon to get more the deets as shown in the screenshot.

Get the extension here: https://lnkd.in/dFFf2snR

Dev par Bas Westerbaan Post-quantum  expert at Cloudflare.

Comment ça marche ?

=> reniflage de x25519MLKEM768 dans le client/serverHello du TLS handshake

Mais ça sert vraiment à quelque chose ?

NON 😉

on peut faire la même chose directement depuis ses devTools 🙂

 

C’était rigolo, j’avais oublié comment c’était stimulant les CTF.
Suis reparti de zéro. Soit à peine moins que le niveau que j’avais au meilleur de ma forme 😉
Mais j’avais vraiment envie de voir à quoi ressemblaient les challenges de crypto et web des années > 2025. Je n’ai pas été déçu.
Mais carrément à poil, même pas un simple Python qui trainait sur un vieux laptop, pas un netcat sur le Windows du boulot ni-même un compte Discord encore actif.
Et puis, tu remontes un environnement avec quelques outils basiques … et tu te reprends au jeu.
Mais tout est devenu si difficile … même le simple « Puissance 4 Baby ». Bon, je n’ai jamais été un furieux du pwn donc ça pique … moi, j’ai fait LSE avec Georges Poupineau en Seconde 2 informatique en 1985.
Bon aujourd’hui, si tu es nul en CTF classique, tu peux toujours te rabattre sur les CTF OSINT et fuir le regard condescendant des top flaggers 🙂

Bref, j’ai joué un peu … je me suis beaucoup lamenté sur mon niveau déplorable, je me suis fait discret, je n’ai pas fait appel à des amis en fait ((drame du high frequency flag Sharing), si … mais ils ne m’ont pas été de grand secours mais ça prouve bien combien le réseau est important dans cet écosystème. Et j’ai patiemment attendu les WU, aha !

Et entretemps testé quelques trucs de guedins qui n’existaient pas il y a 10 ans 🙂 (Parce que même les vieille recettes ne fonctionnent plus toujours … Lol mon install de Ghidra avec mon Java 17). Donc j’ai demandé à Google de me conseiller pour une décompil zen ligne et je suis tombé sur :

https://cloud.binary.ninja/

https://vexcited.com/blog/fcsc-2026/puissance-4-baby/

Et ce sera déjà pas mal !

Mon projet : monter une PKI avec ejbca adossée à 3 openLDAP en multi-maître en backend (avec quelques clefs dans 2 HSM Atos Protecio en réplication. La-dessus, mettre en place un provider d’identité avec keycloack.

Voilà, y’a plus qu’à …

Bref un truc comme ce qu’on avait prévu à Ougadougou en 2016 😉 (avant qu’il ‘y ait le feu à l’Assemblée Nationale

base : https://en.wikipedia.org/wiki/PKCS / https://fr.wikipedia.org/wiki/Public_Key_Cryptographic_Standards

In cryptography, PKCS stands for « Public Key Cryptography Standards ». These are a group of public-key cryptography standards devised and published by RSA Security LLC, starting in the early 1990s. The company published the standards to promote the use of the cryptography techniques to which they had patents, such as the RSA algorithm, the Schnorr signature algorithm and several others. Though not industry standards (because the company retained control over them), some of the standards in recent years have begun to move into the « standards-track » processes of relevant standards organizations such as the IETF and the PKIX working-group.

Les PKCS (Public-Key Cryptography Standards), ou standards de cryptographie à clé publique, sont un ensemble de spécifications conçues par les laboratoires RSA en Californie. La société RSA Security est spécialisée dans les solutions de sécurité cryptographiques. Elle est également propriétaire de licences d’exploitations de plusieurs algorithmes (dont RSA avant l’expiration de son brevet le 21 septembre 2000). C’est pour ces raisons que la société a développé et promu les PKCS, permettant l’implantation des techniques de cryptographie à clé publique.

La société RSA Security n’est pas un organisme de normalisation, et pourtant, elle contrôle complètement l’élaboration et l’évolution des PKCS. L’appellation des PKCS comme standards au sens strict est donc abusive. Répondant à un réel besoin technique, les PKCS ont néanmoins été très largement adoptés par le milieu informatique. Le groupe de travail PKIX de l’IETF a depuis reformulé certains des PKCS dans des RFC, les standards Internet. L’abus de langage confondant le PKCS au lieu de la RFC correspondante est très répandu.

1- revenir sur la place de la cryprographie dans dans le cadre plus large de la cryptologie.

2- flash back sur l’histoire de l’entreprise RSA (https://fr.wikipedia.org/wiki/RSA_Security) ( y compris le leak de 2011)

3- faire une lecture croisée de ressources francophones et internationales

 

	Version	Nom	Commentaires
PKCS#1	2.1	Standard de cryptographie RSA	RFC 34471. Définit le chiffrement et la signature RSA (notamment les schémas de remplissage OAEP, PSS et PKCS1-v1.5).
PKCS#2	–	Obsolète	Décrivait le chiffrement RSA de condensés de message, mais a été intégré dans PKCS#1.
PKCS#3	1.4	Standard d’échange de clés Diffie-Hellman
PKCS#4	–	Obsolète	Décrivait la syntaxe de clé RSA, mais a été intégré dans PKCS#1.
PKCS#5	2.0	Standard de chiffrement par mot de passe	cf. RFC 28982 (rendu obsolète par la RFC 80183) et PBKDF2.
PKCS#6	1.5	Obsolète	Définissait les extensions de l’ancienne spécification de certificat X.509 v1.
PKCS#7	1.5	Standard de syntaxe de message cryptographique	Cf. RFC 23154. Utilisé pour signer et/ou chiffrer des messages dans le cadre d’une infrastructure à clés publiques. Sert également à la transmission de certificats (notamment en réponse à un message PKCS#10). À l’origine de S/MIME, qui est désormais décrit sous le nom Cryptographic Message Syntax (CMS) dans la RFC 56525.
PKCS#8	1.2	Standard de syntaxe d’information de clé privée	Cf. RFC 59586.
PKCS#9	2.0	Types d’attributs sélectionnés	RFC 29857
PKCS#10	1.7	Standard de requête de certificat	Cf. RFC 29868. Format des messages envoyés à une autorité de certification et demandant la signature d’une paire de clés.
PKCS#11	2.20	Interface de périphérique cryptographique (cryptoki)	Une API définissant une interface générique pour périphérique cryptographique.
PKCS#12	1.0	Standard de syntaxe d’information personnelle	Définit un format de fichier généralement utilisé pour stocker la clé privée et le certificat de clé publique correspondant en les protégeant par un mot de passe.
PKCS#13	–	Standard de Cryptographie sur les courbes elliptiques	(En cours de développement)
PKCS#14	–	Générateur de nombres pseudo-aléatoires	(En cours de développement)
PKCS#15	1.1	Standard de format d’information sur les périphériques cryptographiques	Définit un standard permettant aux utilisateurs de périphériques cryptographiques de s’identifier auprès des applications, indépendamment de l’implantation de la cryptoki par l’application (PKCS #11) ou une autre API. La partie de cette spécification concernant les cartes IC a été intégrée dans le standard ISO/IEC 7816-15. [1] [archive]

#PKCS1 se prête très bien à l’illustration d’un des « standards »

Plutôt que de lire des bêtises sur Silicon.fr et son code fantaisiste 4272, jetez plutôt un œil sur l’article de blog de Secura : Instantly Become Domain Admin by Subverting Netlogon Cryptography ou téléchargez le rapport Zerologon by Secura

Autres sources d’inspiration:

la base : le site de l’ANSSI qui explique :

Il est possible, dans certaines conditions, de détecter une tentative d’exploitation qui aurait pu subvenir avant application du correctif de Microsoft, grâce aux journaux générés par Windows.

Pour cela, la politique d’audit « Gestion du compte > Auditer la gestion des comptes d’ordinateur » [2] doit être activée sur les contrôleurs de domaine. Les événements « Un compte d’ordinateur a été modifié », dont l’identifiant est 4742, sont ainsi générés dans le journal de sécurité.

De tels événements sont générés de manière légitime lorsqu’un compte d’ordinateur renouvelle son mot de passe. Néanmoins, l’attaque Zerologon conduit aux spécificités suivantes :

le champ SubjectUserName est « ANONYMOUS LOGON » ;
le champ TargetUserName est le compte machine d’un contrôleur de domaine.

Zerologon Detection (CVE-2020-1472) qui propose la règle suivante : Primary Search for Local Domain Controller Exploitation by Zerologon

index= »<windows_index> » (sourcetype= »<windows_sourcetype_security> » OR source= »windows_source_security ») EventCode= »4742″ OR EventCode= »4624″ AND (src_user= »*anonymous* » OR member_id= »*S-1-0* »)
`comment(« This looks for all 4624 and 4742 events under an ‘ANONYMOUS USER’, which are tied to the exploitation of Zerologon »)`
| eval local_system=mvindex(upper(split(user, »$ »)),0)
`comment(« This effectively splits the user field, which when parsed with the TA for Windows, may also appear as the Target User. Since the exploit would specifically occur using a local account on the Domain Controller, it stands to reason that detecting a modified user object, modified by a local system account, would be evidence of the exploit. The split removes the ‘$’, creating a new field, deriving the local_system name via the original user field [ie. user=’NameOfDC$’ would become local_system=’NameofDC’] »)`
| search host=local_system
`comment(« A search to only find instances of these events when the host (DC) is the same as the extracted local_system account name performing the action »)`
| table _time EventCode dest host ComputerName src_user Account_Name local_system user Security_ID member_id src_nt_domain dest_nt_domain

---

Ressources complémentaires :

ZeroLogon testing script

A Python script that uses the Impacket library to test vulnerability for the Zerologon exploit (CVE-2020-1472).

It attempts to perform the Netlogon authentication bypass. The script will immediately terminate when successfully performing the bypass, and not perform any Netlogon operations. When a domain controller is patched, the detection script will give up after sending 2000 pairs of RPC calls and conclude the target is not vulnerable (with a false negative chance of 0.04%).

 

Sad, no beeing able to assess OpenShift Playground 🙁

 

 

 

 

2 months later 🙁

Ce contenu est protégé par un mot de passe. Pour le voir, veuillez saisir votre mot de passe ci-dessous :

Mot de passe :