Bonjour, je cherche les STUM (Spécifications Techniques d’Utilisaton du Minitel), particulièrement les STUM 10 et STUM 1B.
Si qqun en dispose en papier et accepte de s’en défaire quelques jours, je suis volontaire pour un scan+OCR en PDF.
Note: J’ai repéré les STUCAM sur le site de Pascal Chour
François Grieu
Bonjour @fgrieu et bienvenue parmis nous !!!
Pour le STUM 1B il est ici > http://minitel.cquest.org/musee/minitel/documentation-technique/STUM1B.pdf
Pour le STUM 10 malheureusement je ne le possède pas.
De mon coté recherche le STUM 12 pour la rénovation d’un M12 et c’est vraiment pas facile de le trouvé 
Merci beaucoup pour le « STUCAM » mais il déjà sur le site de cquest ici > http://minitel.cquest.org/musee/minitel/documentation-technique/1987-08-25_stucam_parties_1_et_2.pdf
Cordialement.
F4GXS Pierre.
Bonjour François, soit le bienvenu !
Que cherches-tu de particulier sur les STUM du M10 ?
Tout ce que j’ai est ici: http://minitel.cquest.org/musee/minitel/documentation-technique/
Le M10 apporte surtout le module téléphonique et il est décrit dans les STUM du M2.
Merci pour les liens, c’est ce que je cherchais. J’ai perdu ces specs dans un déménagement, et je voulais les retrouver par nostalgie: j’ai passé tellement de temps à faire le hard et une partie du soft d’émulateurs Minitel: carte AppleTell pour Apple 2, divers modems Apple, une petite partie du logiciel MacTell, modem Quadristandard aka Iseut qui émule aussi le Lecam…
Un modem-lecam a existé ?
Un jour, j’ai trouvé un type sur LinkedIn qui disait avoir rédigé le stum12 (que je n’ai jamais vu)
Oui, un modem-Lecam a existé, avec implémentation des aiguillages,de I’interpréteur du language spécifique, de l’algorithme semi-secret « Générateur d’Octets Chiffrant ». Une version avec la pomme Apple a même été vendue par Apple France.
C’est une implémentation « Clean Room », sur laquelle 4 personnes dont moi on travaillé, pendant de mémoire près de 2 ans calendaire. J’ai encore le source de la dernière version, pour un assembleur 8051 spécial qui ne tourne que sous MPW, sous MacOS 9 ou antérieur (je sais encore le faire fonctionner, l’assembleur est écrit en Pascal, j’ai le source aussi). La partie affichage était sur l’ordi (genre Macintosh avec MacTell).
« STUM12 » me dit vaguement quelque chose, et il y a une référence ici.
Ah ba voilà, on va être au moins deux à pouvoir papoter à propos d’MPW !
J’ai recompilé Dragster, serveur pour Macintosh, il y a quelques années pour retirer les protections… l’occasion de refaire du MPW Pascal (et assembleur 68000).
C’est indiqué sur la page non numéroté après la 106 sur le STUM2
C’est Jean-Bernard DAIAN qui a rédigé le STUM2 et 12, il était chez « ALCATEL BUSINESS SYSTEMS » - Adjoint Support Technique International de 1988 a 1995
Peut être qu’on devrais le contacter pour avoir des infos sur le STUM12 malheureusement manquant a notre collection…à suivre.
« Algo semi-secret » … C’est ce qui nous avait arrêtés
Chercher à recontacter jean-Bernard Daian serait une bonne idée … Je ne suis pas champion de LinkedIn, et, y est-il encore actif ? Qui s’y colle ?
Oui c’est un cv très détaillé
J’ai lu les stucam 1987, le générateur d’octets chiffrants me semble biaisé dès le départ. Il fonctionne avec une clé de 64 bits mais la réduit à 48 bits, ca ressemble à une backdoor.
Bon d’un autre côté jusqu’en 1999 le chiffrement était considéré comme une arme de guerre en France et soumise à autorisation, donc normal que tous ces algorithmes étaient backdoorés.
J’ai encore le source de la dernière version, pour un assembleur 8051 spécial qui ne tourne que sous MPW, sous MacOS 9 ou antérieur (je sais encore le faire fonctionner, l’assembleur est écrit en Pascal, j’ai le source aussi).
Disposez-vous des sources de la partie GOC (générateur d’octets chiffrants) ? étant assez spécialiste du chiffrement ça m’intéresserait de l’analyser. Le reste du code source ne m’intéresse pas.
Je suppose que le terme « semi-secret » ne doit plus être d’actualité pour un algorithme avec clé effective de 44 bits alors que n’importe quel personne utilise de l’AES 256 bits pour se connecter sur son site bancaire.
De plus pour la signature d’un message le comprimé (hash du message) est de 32 bits !
Alors que MD2 avait déjà 128 bits !
Un hash de message de 32 bits tombe avec l’attaque des anniversaires. On peut donc générer deux messages identiques (ordre de virement bancaire par minitel par exemple) en seulement 2^16 essais (65536 essais).
Oui, j’ai encore les sources de la partie GOC (faits d’après la doc officielle, que je n’ai hélas plus)… Et j’avais même envisagé de le transformer en quelque chose d’intelligible avec vecteurs de test et de le publier (voir ce post qui donne aussi quelques pointeurs). Je vais réexaminer ça (prendra quelques jours). Je referais un post ici.
Je ne suis pas spécialiste des sites web de brevets mais apparemment on ne peut pas consulter le brevet lui-même sur le site que vous aviez cité, je me trompe ou pas ?:
The GOC is described in exquisite detail in patent FR2519828A2, assigned to the French state
Par contre j’ai trouvé ce qui semble le même genre de brevet mais déposé au niveau européen.
On y apprend que le GOC a été créé pour le système ANTIOPE qui utilisait des caractères à 5 bits, les bits 6 et 7 étant utilisés pour des commandes (qui sont envoyées en clair), le bit 8 la parité.
La clé K fait 64 bits est initialisée par le numéro de page Antiope (de 001 à 999 codée sur 3 octets) et le numéro de rangée caractère (de 1 à 24).
Vous disiez :
In summary, the GOC has a 64-bit key; a state of 109 bits (organized as 19 bytes); and produce 5 pseudo-random bits at each step, which involves a dozen elementary operations on bytes: XOR, addition, modified modular reduction mod 31 or 127 reducing to some subtractions.
En fait ce qui semble impressionnant a priori : les 109 éléments binaires, est tout de suite moins impressionnant quand on y regarde de plus près :
Les 109 éléments binaires sont répartis comme suit :
-35 bits pour les registres R
-49 bits pour les registres S
-25 bits pour les registres T
Et en fait les registres R,S et T sont de tout petits registres de 5 bits et 7 bits (d’où le modulo 31 et le modulo 127).
Les sorties de ces registres rebouclent vers d’autres registres.
Le premier problème que l’on observe c’est qu’étant adapté au système Antiope et ne chiffrant que 5 bits par octets, les bits 6 et 7 du videotexte sont donc en clair (à moins que j’ai mal compris). On connaît donc 2 bits clair par caractère chiffré.
A cela s’ajoute le fait que sur la K de 64 bits des bits sont fixes (numéro de série de la carte) et qu’il n’y a que 44 bits effectifs.
Reste à étudier l’algorithme réel, qui est quand même compliqué à recréer sans se tromper uniquement à partir du brevet.
I have short portable C code that I wrote from specs, and a KAT, which (I believe) match deployed implementations. I could post that as part of the question, or elsewhere.
Oui si vous avez aussi ces éléments là en plus du code source, ce serait parfait.
C’est possible. Partant de FR2519828A2, cliquer Français, Document original, Télécharger. Résoudre le captcha, et on obtient le document en pdf. La fin d’une page est abimée, mais je pense que c’est une table non essentielle et que l’on retrouve dans les versions étrangères.
J’ai retrouvé 3 implémentations dont je suis l’auteur: en Pascal, en assembleur 68000 (de1988), et une traduction en C (de 2011). Il y a un vecteur de test (de 1988) qui utilise la clé
12 34 56 78 90 AB CD EF
et produit les octets
14 1C 10 18 1C 01 0D 1B 07 1D 13 0B 19 1C 05 02 12 11 0A 16 07 05 1E 18 03 18 06 0C 0B 0B 07 1E 11 14 13 07…
Je découvre avec joie que ce code est aussi conforme au vecteur de test du brevet: clé de la page 18, droite des lignes 1 à 8, octets chiffrants page 20, lignes 17-18 (à ceci près que dans le brevet le bit de poids fort est ajusté pour une parité paire).
J’ai aussi une implémentation en source 8051 (incluant la variante « condensé ») et tout son contexte pour une émulation LECAM fonctionnelle. Je l’ai réassemblée ce matin. Je suis très confiant qu’elle est fidèle au LECAM car c’était dans un produit commercial (et même vendu par Apple avec la pomme multicolore dessus). Mais ce n’est pas moi l’auteur de la partie LECAM, c’est dur à comprendre, je n’ai pas trouvé de vecteur de test, et je n’ai rien sous la main pour la faire tourner.
Mon source C et sa démo (merci tio.run) avec 3 vecteurs de test.
J’ai aussi réécrit cela de façon plus moderne, avec les registres R S T dans 3 variables de 64 bits au lieu de 19 octets, et avec le calcul du modulo à temps constant. Le résultat est bien sur équivalent au code ci-dessus. Je l’ai publié ici en demandant comment on ferais une cryptanalyse.
J’ai pu télécharger le brevet français, merci. C’est le même que le brevet européen.
Avez-vous la possibilité de publier aussi les autres sources (pascal, assembleur 68000 et 8051 ?)
Car pour le moment il manque le protocole, à savoir:
-comment est géré la sortie de la carte à puce. Si c’était bien du DES, la clé fait 56 bits.
-Or les stucam indiquent que seuls 44 bits forment la clé, le reste des bits jusqu’à 64 est formé par des bits fixes (numéro de série de la carte).
-Comment est formée cette clé de 44 bits.
-Est-ce que les bits 6 et 7 d’une page vidéotexte minitel sont bien en clair? (vu que le GOC ne produit que des mots de 5 bits et le bit 8 est juste la parité).
-comment sont gérés les vecteurs d’initialisation pour chiffrer une page vidéotexte (les fameux numéros de page et numéro de colonne antiope)
-extraire l’algorithme de création du condensé de 32 bits.
Je pense que seules vos autres sources peuvent répondre à ces questions.
Pour le 8051 il y a ces deux compilateurs:
et les simulateurs 8051 :
Le source Pascal et celui assembleur 68000 ne font que le GOC, pas son initialisation ni utilisation, ni même la variante condensé. Ils n’apportent strictement rien de plus que mes versions C (ci-dessus avec état en 19 octets, et là avec 3 registres plus larges).
Le code 8051 fait a priori tout le Lecam, mais j’hésite à le publier sans l’accord des 3 autres auteurs et d’un ayant droit. Et il utilise un assembleur 8051 avec des caractéristiques uniques (tout le source s’assemble d’un coup sans linker, labels locaux introduits par le signe §…) et un assembleur du langage Lecam dont je ne retrouve que l’exécutable MPW. Au total le source fait 45k lignes, beaucoup sans rapport avec le minitel ou le Lecam. Je fais plutôt essayer de répondre aux questions que vous posez, en citant des extrait du code source 8051 ou Lecam.
Une facile:
Oui en mode « Videotex ». Petit extrait du code (relativement clair dans cette partie)
;————————————————————————————————————————————————————————————————————————————————————————————————————
;ILSkipVidIdle
; Si le caractère courant n'est pas un caractère de contrôle, on le déchiffre et on l'émet
; (à condition que la consigne CH soit d'accord), sinon on l'émet sans le déchiffrer.
ILSkipVidIdle
CALL ILGetdcfcByte ;ne revient pas si pas de déchiffrement
MOV R1,A
CJNE A,#$20,*+3
JC §testESC
MOV R7,A
IF DEBOG
CALL PRBYTE
ENDIF
;————————————————————————————————————————————————————————————————————————————————————————————————————
;Suivant la valeur de AC, CH & CM va:
; Si le bit b de AC est positionné, on va initialiser le tampon de saisie
; au cas où la saisie serait simple ***à définir***
MOV DPTR,#xILACParms
MOVX A,@DPTR
JNB Acc.kILACs,§11
MOV A,R1
JMP ILGocSign
§11 MOV DPTR,#xILCHParms
MOVX A,@DPTR
JNB Acc.kILCHc,§toScreen
SETB C ;on utilise le Goc de chiffrement.
CALL ILGetGocByte
IF DEBOG
CALL PRBYTE
PUSH Acc
MOV A,R7
CALL PRBYTE
POP Acc
ENDIF
ANL A,#$1F ;en mode videotex un octet Goc pour un octet Videotex
XRL A,R7
MOV R7,A
MOV DPTR,#xILACParms
MOVX A,@DPTR
JNB Acc.kILACb,§toScreen
MOV DPTR,#xILDefSSBlock
MOVX A,@DPTR
MOV DPH,A
MOV DPL,#6
MOVX A,@DPTR
INC A
MOVX @DPTR,A
ADD A,#6
XCH A,DPL
MOV A,R7
MOVX @DPTR,A
IF DEBOG
CALL PRSTRING
DB kCr,"--7- $",0
CALL PRBYTE
CALL PRSTRING
DB " '",0
CALL COUT
CALL PRSTRING
DB "' in Def",0
ENDIF
RET
§toScreen MOV DPTR,#xILACParms
MOVX A,@DPTR
JNB Acc.kILACa,§NoEcho
MOV DPTR,#xILCMParms
MOVX A,@DPTR
JNB Acc.kILCMd,§NoEcho
MOV A,R7
JMP ILSend2ScrOnly
§NoEcho RET
§testESC CJNE R1,#kESC,§testUS
MOV A,R1
CALL ILSend2ScrOnly
MOV DPTR,#ILSkipVidESC
JMP ILSetSkipVid
§testUS CJNE R1,#kUS,§testSEP
MOV A,R1
CALL ILSend2ScrOnly
MOV DPTR,#ILSkipVidUS
JMP ILSetSkipVid
§testSEP CJNE R1,#kSEP,§testSS2
MOV A,R1
CALL ILSend2ScrOnly
MOV DPTR,#ILSkipVidSEP
JMP ILSetSkipVid
§testSS2 CJNE R1,#kSS2,§testCipher
MOV A,R1
CALL ILSend2ScrOnly
MOV DPTR,#ILSkipVidSS2
JMP ILSetSkipVid
§testCipher ;actions <> suivant chiffr…t ou sign… sur 0/X et 1/X
§RET RET
;————————————————————————————————————————————————————————————————————————————————————————————————————
Cependant il y a d’autres cas où le GOC est utilisé 2 fois par octet, en groupant les 4 bits de poids faible des 2 résultats (poids fort pour le premier GOC) pour faire un masque de 8 bits.
De ce que je trouve dans le source, les STUCAM, et mes souvenirs, le Lecam ne fait jamais l’opération de dérivation de clé à partir du numéro de page etc comme spécifié dans Antiope et dans le brevet.
Avec une confiance de 80%; les 8 octets qui initialisent le GOC de chiffrement sont parfois entièrement produits par la carte à puce par une méthode cryptographique. Cela dépends de la carte, que le Lecam reconnais. Certaines cartes génèrent cette clé par l’algorithme Telepass (que j’aimerais bien trouver !) d’autres (ultérieures) DES. Quand DES est utilisé, la clé est 56-bit, et c’est sans doute le maillon faible pour une attaque par force brute. Mais la clé GOC est 64-bit et je conjecture qu’une attaque par cryptanalyse du GOC est plus efficace.
Merci pour les pointeurs sur les outils 8051. Je réserve ça pour quand/si j’ai du temps.
Merci pour ces informations.
Il reste quelques inconnues, le code source l’indique t’il ?
Cependant il y a d’autres cas où le GOC est utilisé 2 fois par octet, en groupant les 4 bits de poids faible des 2 résultats (poids fort pour le premier GOC) pour faire un masque de 8 bits.
Dans quels cas le chiffrement n’est que sur les 5 premiers bits et dans quels cas il y a 2 GOC par octet ?
De ce que je trouve dans le source, les STUCAM, et mes souvenirs, le Lecam ne fait jamais l’opération de dérivation de clé à partir du numéro de page etc comme spécifié dans Antiope et dans le brevet.
Y a t’il un vecteur d’initialisation? comment est il généré et à quel moment? à chaque page? lors de l’arrivée sur le site? et si il y a erreur de réception comme s’effectue la resynchronisation du GOC ?
Quand DES est utilisé, la clé est 56-bit, et c’est sans doute le maillon faible pour une attaque par force brute. Mais la clé GOC est 64-bit et je conjecture qu’une attaque par cryptanalyse du GOC est plus efficace.
Comment est formée la clé de 44 bits à partir de la clé DES de 56 bits?
L’attaque sur l’algorithme pur est une chose mais le protocole semble encore plus faible.
Donc il y a surement d’autres attaques possibles en condition réelle avec connaissance du protocole.
Sans être sur de couvrir tous les cas:
Pas de vecteur d’initialisation, mais il y a a un mécanisme de réinitialisation explicite (par le programme de l’interpréteur LECAM, lui-même piloté par le serveur ou peut-être le PAVI) qui comprend un octet « synchro » pour une dérivation sommaire de la clé, par OU exclusif, qui (bien utilisé) permet de ne pas réemployer les mêmes octets chiffrants. Voir consigne CH (page 97). Il est aussi possible de repositionner le GOC à un rang donné par la consigne PR (page 97).
Je me souvient confusément d’une grande difficulté à trouver des serveurs avec ces mécanismes en action. Et que souvent, quand le chiffrement est employé, il est en combinaison avec la protection des échanges par CRC, pour prévenir la désynchronisation plutôt que la guérir.
En tout cas avec la carte bancaire M4,B0 ou M6, le TelePass ou DES est exécuté par la carte, avec une clé gardée secrète par la carte, de 8 octets (dont 56 bits signficatifs pour DES, je ne sais pas pour TelePass). Le résultat de 64 bits est (que je sache intégralement) utilisé comme clé GOC. Le mécanisme pour cela est que le Lecam reconnais l’APDU carte qui déclenche Telepass ou DES, intercepte le résultat carte (plus de détails page 137), et l’utilise comme clé GOC par l’intermédiaire de la consigne CH (page 97). Il y a un mécanisme où des cartes futures contiennent un bloc d’information qui décrit quel ordre équivalent elles utilisent.
Quelle est la source de « clé de 44 bits » et dans quel cas ce serait, que je regarde ?