Microsoft dépose un brevet qui ravirait la Hadopi, Réactions à la publication du 16/05/2017

[Lionel]

Microsoft a déposé un brevet dont voici le résumé officiel:

Les objets dans un système de stockage partagé peuvent être marqués comme incluant des contenu illicites. Les incidents dans lesquels des documents marqués ont été découverts peuvent être stockés dans un historique d'incident associé à un utilisateur responsable de ces objets. L'historique des incidents peut être traité pour identifier les récidivistes et modifier les privilèges d'accès de ces utilisateurs. Cependant, lorsque les objets sont partagés par un utilisateur avec un autre utilisateur, le contenu interdit est bloqué, mais le reste des objets partagés peut être consulté par l'autre utilisateur. Les fonctions qui permettent le partage du contenu sont mises en place de manière à empêcher le partage de contenu interdit avec un autre utilisateur tout en permettant l'échange d'autres contenus. Si un groupe de fichiers ou d'objets est partagé, la présence de contenu interdit dans un objet du groupe entraîne le non-partage de ce contenu interdit, mais les fichiers ou les objets restants sont toujours partagés.


En bref, Microsoft a déposé un brevet destiné à éventuellement inclure dans des systèmes d'exploitation la surveillance des fichiers contenus et le blocage d'éventuels contenus illicites ou obtenus illégalement.

Nous présumons que la société n'aura pas la folie suicidaire de vouloir imposer cette surveillance dans tous les Windows. Nous présumons que cela serait plutôt réservé aux versions S de Windows destinées au monde de l'éducation et à des machines prêtées ou mises à disposition d'étudiants.

Lien vers le billet original

[Pixelux]

Il y a pas mal de monde qui quittent Windows pour Linux à cause de ce genre de problème lié à la vie priver.

[SartMatt]

En bref, Microsoft a déposé un brevet destiné à éventuellement inclure dans des systèmes d'exploitation la surveillance des fichiers contenus et le blocage d'éventuels contenus illicites ou obtenus illégalement.

Non, pas de surveillance des contenus. Le brevet ne parle pas de détection automatisée des contenus illicites, mais simplement de proposer aux fournisseurs de services de stockage des moyens de marquer les contenus qui leur ont été signalés comme illicites pour empêcher leur partage (plutôt que de les supprimer comme c'est généralement le cas actuellement) et pour garder un historique des signalements concernant chaque utilisateur et des signatures des fichiers bloqués (pour qu'ils ne puissent pas être partagés en les ré-uploadant sur le service).

[__otto__]

Ca peut en effet concerner les données sous copyright... mais c'est aussi un très bon outil pour éviter de futurs Snowden de pouvoir partir avec les données... et ça c'est autrement plus dangereux pour nous...

[chombier]

En bref, Microsoft a déposé un brevet destiné à éventuellement inclure dans des systèmes d'exploitation la surveillance des fichiers contenus et le blocage d'éventuels contenus illicites ou obtenus illégalement.

Non, pas de surveillance des contenus. Le brevet ne parle pas de détection automatisée des contenus illicites, mais simplement de proposer aux fournisseurs de services de stockage des moyens de marquer les contenus qui leur ont été signalés comme illicites pour empêcher leur partage (plutôt que de les supprimer comme c'est généralement le cas actuellement) et pour garder un historique des signalements concernant chaque utilisateur et des signatures des fichiers bloqués (pour qu'ils ne puissent pas être partagés en les ré-uploadant sur le service).

Ouais. Une nouvelle forme de censure. Qui décide de ce qui est illicite ? Le dictateur président Erdoğan ?

[Pixelux]

En bref, Microsoft a déposé un brevet destiné à éventuellement inclure dans des systèmes d'exploitation la surveillance des fichiers contenus et le blocage d'éventuels contenus illicites ou obtenus illégalement.

Non, pas de surveillance des contenus. Le brevet ne parle pas de détection automatisée des contenus illicites, mais simplement de proposer aux fournisseurs de services de stockage des moyens de marquer les contenus qui leur ont été signalés comme illicites pour empêcher leur partage (plutôt que de les supprimer comme c'est généralement le cas actuellement) et pour garder un historique des signalements concernant chaque utilisateur et des signatures des fichiers bloqués (pour qu'ils ne puissent pas être partagés en les ré-uploadant sur le service).

Ouais. Une nouvelle forme de censure. Qui décide de ce qui est illicite ? Le dictateur président Erdoğan ?

N'importe qui moyennant finance...

[SartMatt]

Ouais. Une nouvelle forme de censure. Qui décide de ce qui est illicite ? Le dictateur président Erdoğan ?

Ce n'est pas la question de ce brevet. Ce brevet parle de la façon de gérer ce qui a été signalé comme illicite. Pas de qui décide ce qui est illicite.

Actuellement, ce sont généralement les ayant-droits qui signalent les contenus illicites dont ils sont titulaires des droits, tout simplement (même si ils font hélas parfois preuve d'un excès de zèle, conduisant à des demandes de blocage sur des contenus licites où sur lesquels ils n'ont pas les droits). Et non, ça n'est pas de la censure.

[chombier]

Ouais. Une nouvelle forme de censure. Qui décide de ce qui est illicite ? Le dictateur président Erdoğan ?

Ce n'est pas la question de ce brevet. [...] Et non, ça n'est pas de la censure.

Tu ne serais pas partie prenante par hasard ?

[SartMatt]

Ca peut en effet concerner les données sous copyright... mais c'est aussi un très bon outil pour éviter de futurs Snowden de pouvoir partir avec les données... et ça c'est autrement plus dangereux pour nous...

Parce que tu crois que pour sortir les documents, Snowden les a envoyés vers un système de stockage partagé ?

Et quand bien même ça serait le cas, pour les bloquer, faudrait que le système de stockage partagé connaisse à l'avance les signatures de ces fichiers. Tu crois que la NSA (ou autre) va s'amuser à donner les signatures de tous ses fichiers à tous les services de stockage ?

Et quand bien même ça serait le cas, il suffit de foutre les documents dans un zip chiffré pour que la signature disparaisse comme par magie et que même le mieux informé des systèmes de stockage ne soit plus capable de le reconnaitre...

Ouais. Une nouvelle forme de censure. Qui décide de ce qui est illicite ? Le dictateur président Erdoğan ?

Ce n'est pas la question de ce brevet. [...] Et non, ça n'est pas de la censure.

Tu ne serais pas partie prenante par hasard ?

Non. Juste partie qui prend la peine de réfléchir

Ce brevet ne parle en aucun cas de qui décide qu'un contenu est illicite. Et bloquer des contenus illicite, ça n'est pas de la censure ("La censure est la limitation arbitraire ou doctrinale de la liberté d'expression de chacun"), c'est la loi qui détermine si un contenu est illicite.

Ce message a été modifié par SartMatt - 15 May 2017, 23:39.

[chombier]

Non. Juste partie réfléchissante.

Et bien je te propose de réfléchir un peu plus loin.
Le zip chiffré peut aussi être considéré "illicite"...
Bien souvent, l'homme a inventé quelque chose pour améliorer son existence. Par exemple le briquet ou le téléphone.
Et maintenant, il y a des lance-flammes et des démarcheurs téléphoniques (ta mère).

[iAPX]

C'est intéressant comme Brevet, avec tout ce qu'il amène comme questionnement, notamment ici.

Un des problèmes qui n'est pas abordé est le contrôle des usagers sur leur fichiers, mais un autre est aussi qui contrôle ces droits, in fine.

Par exemple j'ai une photo, que j'ai faite, hors contrat, qui m'appartient, dont je suis le propriétaire de tous les droits.
Si je devais la signaler quelque-part (peu importe où et comment) comme ayant été utilisé indûment à mon insu, est-ce qu'il n'y aurait pas un risque que moi-même je ne puisse plus la partager avec les personnes ou les compagnies que je choisi?

Je pense que tous les producteurs de contenu devraient avoir extrêmement peur avec ce brevet, et ça tombe bien la nouvelle version de Windows 10 (dont Microsoft se lavera les mains dans 3ans, en 2020, même si c'est buggé à l'os), s'appelle "Creators Update" et la prochaine "Fall Creators update", pas sur que "Fall" soit pour l'automne ou pour la chute des créateurs

Avec Windows 10, et ces nombreux systèmes de tracking et d'accumulation de données, dont un keylogger intégré (si fallait l faire!), Microsoft va vraiment trop loin!

Ce message a été modifié par iAPX - 15 May 2017, 23:41.

[Ze Clubbeur]

De toute façon, quand on voit comment il est simple d'activer Windows ou les produits Microsoft, je ne me fais pas trop de soucis pour ce qui est de la pérennité d'un tel système... lol

[SartMatt]

Non. Juste partie réfléchissante.

Et bien je te propose de réfléchir un peu plus loin.
Le zip chiffré peut aussi être considéré "illicite"...

Oui bien sûr, le zip chiffré peut être considéré comme illicite. Si on interdit les zip chiffrés.

Mais comme la signature du fichier chiffré ne peut par définition pas être connue à l'avance, il n'est pas possible de le bloquer à priori. On ne peut le bloquer qu'à posteriori, une fois qu'il a été identifié. Et du coup, ça n'empêche pas de sortir des données, une fois qu'elles sont identifiées et bloquées c'est trop tard, elles sont déjà sorties depuis longtemps. Bien sûr, si la loi interdisait les archives chiffrées, ça serait relativement facile de les détecter à priori, non pas en calculant la signature du fichier, mais en regardant son en-tête pour détecter les formats d'archives chiffrés connus (mais ce n'est pas ce que Microsoft propose dans son brevet, son brevet parle de hash du contenu). Et même comme ça, difficile voire impossible de détecter à priori une archive chiffrée de format non connue, de format à en-tête chiffrée (donc aucune en-tête reconnaissable dans le fichier, seul celui qui sait quel est le format du fichier peut l'utiliser) ou des données chiffrées bien cachées dans des données non chiffrées et anodines (stéganographie et autres trucs du genre...).

Fondamentalement, le système que propose Microsoft ne change de toute façon pas grand chose à ce qui est actuellement en place chez les fournisseurs de stockage partagés, si ce n'est que ça se contente de bloquer le partage des contenus signalés comme illicites, alors que les fournisseurs de stockages partagée font actuellement de la suppression pure et simple quand les contenus sont signalés.

Ce message a été modifié par SartMatt - 15 May 2017, 23:49.

[marcmame]

Il y a pas mal de monde qui quittent Windows pour Linux à cause de ce genre de problème lié à la vie priver.

Vous me faites marrer. Si j'installe Chrome OS je n'aurais plus de problèmes lié à la vie privée ?
Ca fait 25 ans qu'on nous bassine avec Linux.
25 ans que la part de marché de Linux ne dépasse pas les 2% (1,5% actuellement) pendant que Windows est à 90% et si on ne prend en compte que les desktop grand public ce n'est même plus visible.
Linux n'est pas une alternative à Windows et ne l'a jamais été, en tout cas pas pour le commun des mortel.
Linux c'est fait pour les super ordinateurs, les systèmes embarqués, les entreprises où il y a des DSI et les geek (avec ou sans boutons)

[chombier]

Non. Juste partie réfléchissante.

Et bien je te propose de réfléchir un peu plus loin.
Le zip chiffré peut aussi être considéré "illicite"...

Oui bien sûr, le zip chiffré peut être considéré comme illicite. Si on interdit les zip chiffrés.

Mais comme la signature du fichier chiffré ne peut par définition pas être connue à l'avance, il n'est pas possible de le bloquer à priori. On ne peut le bloquer qu'à posteriori, une fois qu'il a été identifié. Et du coup, ça n'empêche pas de sortir des données, une fois qu'elles sont identifiées et bloquées c'est trop tard, elles sont déjà sorties depuis longtemps.

Alors y'a un truc qui s'appelle "DPI" pour Deep Packet Inspection, et qui tourne sur de nombreux routeurs sur la planète. Et un zip avec mot de passe c'est très facilement identifiable. Y'a un bit quelque-part qui dit que le contenu est chiffré, c'est du gâteau pour ce genre de produit.

[SartMatt]

Alors y'a un truc qui s'appelle "DPI" pour Deep Packet Inspection, et qui tourne sur de nombreux routeurs sur la planète. Et un zip avec mot de passe c'est très facilement identifiable. Y'a un bit quelque-part qui dit que le contenu est chiffré, c'est du gâteau pour ce genre de produit.

Et ça n'a donc plus rien à voir avec ce que décrit ce brevet, qui ne parle pas d'analyse de données, mais simplement de gestion d'un marqueur Et le DPI, ça existe déjà, donc ce brevet n'apporte rien de nouveau à ce sujet.

Accessoirement, comme je l'ai dit plus haut, un fichier chiffré n'a pas nécessairement une en-tête indiquant que c'est un fichier chiffré (et même un zip standard, s'il est transmis via une liaison chiffré, un routeur avec DPI ne saura pas le reconnaitre).

Ce brevet, ça montre juste que Microsoft envisage de proposer une solution "standardisée" pour permettre aux fournisseurs de stockage de gérer les signalement de fichiers illicites, en remplacement des solutions maison que ces mêmes fournisseurs de stockage ont sans doute déjà à peu près tous pour satisfaire à leurs obligations légales (et ceux qui n'en ont pas parce qu'ils s'en foutent des obligations légales, ils n'utiliseront tout simplement pas la solution Microsoft).

Ce message a été modifié par SartMatt - 15 May 2017, 23:59.

[Guest_anonym_d019ede3_*]

Ils ne font que mettre en avant leurs obligations de textes légaux rapport à SACD & Cie

Edit Je pense même qu'ils s'en battent l'aile une fois le message annoncé. S'ils devaient ou voulaient faire plus, ça serait direct violation de fichiers et nanana d'internet et c'est pas du tout la pub qu'ils recherchent et surtout pas en ce moment.

Ce message a été modifié par anonym_d019ede3 - 16 May 2017, 00:36.

[chombier]

Linux c'est fait pour les super ordinateurs, les systèmes embarqués, les entreprises où il y a des DSI et les geek (avec ou sans boutons)

Linux, c'est aussi le noyau qui tourne sur tous les mobiles Android...

[chombier]

Accessoirement, comme je l'ai dit plus haut, un fichier chiffré n'a pas nécessairement une en-tête indiquant que c'est un fichier chiffré

Sérieux ? un zip chiffré, mais pas vraiment ?

The extra data header ID for AES encryption is 0x9901

[SartMatt]

Accessoirement, comme je l'ai dit plus haut, un fichier chiffré n'a pas nécessairement une en-tête indiquant que c'est un fichier chiffré

Sérieux ? un zip chiffré, mais pas vraiment ?

The extra data header ID for AES encryption is 0x9901

Un zip chiffré à forcément une entête en clair indiquant que c'est un fichier chiffré, parce que le format zip a été défini comme ça.

Mais un fichier chiffré n'est pas forcément un zip, et on peut très bien avoir un fichier chiffré ne contenant pas d'entête reconnaisable, parce que l'entête est également chiffrée​. Dans ce cas, seule une personne connaissant le format du fichier et la clé peut reconnaître le fichier.

Et le chiffrement entête compris, ça existe déjà. C'est par exemple le cas des volumes TrueCrypt, ils n'ont pas d'entête en clair. Si tu donnes un volume quelconque à TrueCrypt et lui demande de l'ouvrir avec une clé quelconque, il va te jeter, mais en étant techniquement incapable de te dire si c'est parce que le volume n'est pas un volume TrueCrypt ou si c'est parce que tu as donné une mauvaise clé.

[marcmame]

Linux c'est fait pour les super ordinateurs, les systèmes embarqués, les entreprises où il y a des DSI et les geek (avec ou sans boutons)

Linux, c'est aussi le noyau qui tourne sur tous les mobiles Android...

C'est un système embarqué. De plus, seul le kernel est un linux modifié, sinon l'OS fait partie de la famille des UNIX-like

Ce message a été modifié par marcmame - 16 May 2017, 00:35.

[chombier]

Linux c'est fait pour les super ordinateurs, les systèmes embarqués, les entreprises où il y a des DSI et les geek (avec ou sans boutons)

Linux, c'est aussi le noyau qui tourne sur tous les mobiles Android...

C'est un système embarqué.

J'ai failli faire la remarque, mais avec un clavier et un écran, j'ai un doute...

[marcmame]

...

Ce message a été modifié par marcmame - 16 May 2017, 00:35.

[iAPX]

Tiens, je vais revenir là-dessus, ayant travaillé pour une compagnie de stockage en ligne et de partage de fichiers (le vrai business!), comme employé et actionnaire, puis après revente à un américain (suite aux évènements que beaucoup ont suivi) comme consultant.

Le premier point est que les fichiers partagés sont souvent des films, voire de la musique, mais une sortie de blockbuster nous faisait justement utiliser notre boost à 8Gb/s, on était préparé et on savait le détecter, ça fait plus d"un film par seconde en SD, le jour de la sortie!

Le second point est qu'il y avait beaucoup beaucoup d'autres sortes de films, des films pour certains "dégueulasses", que personne n'aurait signalé ne voulant prendre une part de responsabilité là-dedans, j'ai à ds moment décidé de virer ces contenus en me disant que personne n'oserait se plaindre de leur disparaition et que si fuite d'utilisateur il y avait je n'étais pas géné de gagner moins d'argent avec ce genre de salopards.
Je n'attendais que ça: un choix personnel et prêt à leur en mettre plein la gueule pour leur dégueulasserie. Ah oui je ne peut pas dire pourquoi j'agis comme ça, le viol d'enfant on peut en dire du mal, mais pas pourquoi on lutte, au moins ici.

Mais ce que Microsoft propose là, ça me gêne, notamment avec ce qui manque dans le brevet: qui décide ce qui est illicite ou illégal?
Au nom de quoi et de qui?
Si tu travailles dans l'industrie cinématographique ou la photo, la musique, etc, n'as-tu pas le droit de partager ayant ls droits pour le faire?
Microsoft ne se mouille pas, il offre l'arme fatale pour faire avancer des lois délirantes sur la protection des droits, quitte à un autre de prendre la responsabilité de ces mesures, et ça me fait peur!

Ce message a été modifié par iAPX - 16 May 2017, 00:39.

[SartMatt]

Mais ce que Microsoft propose là, ça me gêne, notamment avec ce qui manque dans le brevet: qui décide ce qui est illicite ou illégal? Au nom de quoi et de qui? Si tu travailles dans l'industrie cinématographique ou la photo, la musique, etc, n'as-tu pas le droit de partager ayant ls droits pour le faire? Microsoft ne se mouille pas, il offre l'arme fatale pour faire avancer des lois délirantes sur la protection des droits, quitte à un autre de prendre la responsabilité de ces mesures, et ça me fait peur!

Ce qui "manque" dans le brevet est tout simplement déjà dans la loi. Je sais pas ce qu'il en est au Canada, mais en France si l'ayant-droit d'un contenu partagé signale à l'hébergeur que le partage est fait sans son accord, l'hébergeur est tenu d'agir. S'il n'avait pas, sa responsabilité est engagée en cas d'attaque en justice et il peut être accusé de contrefaçon (mais pas s'il n'y a pas eu de signalement par l'ayant droit, l'hébergeur n'étant pas tenu de s'assurer à priori de la légalité des fichiers qu'il héberge).

Il y a quelques abus (des non titulaires des droits qui signalent des fichiers, comptant sur le fait que l'hébergeur ne prendra pas la peine de vérifier la légitimité du signalement...), mais globalement il me semble que ça reste assez marginal.

[chombier]

Accessoirement, comme je l'ai dit plus haut, un fichier chiffré n'a pas nécessairement une en-tête indiquant que c'est un fichier chiffré

Sérieux ? un zip chiffré, mais pas vraiment ?

The extra data header ID for AES encryption is 0x9901

Un zip chiffré à forcément une entête en clair indiquant que c'est un fichier chiffré, parce que le format zip a été défini comme ça.

Mais un fichier chiffré n'est pas forcément un zip, et on peut très bien avoir un fichier chiffré ne contenant pas d'entête reconnaisable, parce que l'entête est également chiffrée​. Dans ce cas, seule une personne connaissant le format du fichier et la clé peut reconnaître le fichier.

Et le chiffrement entête compris, ça existe déjà. C'est par exemple le cas des volumes TrueCrypt, ils n'ont pas d'entête en clair. Si tu donnes un volume quelconque à TrueCrypt et lui demande de l'ouvrir avec une clé quelconque, il va te jeter, mais en étant techniquement incapable de te dire si c'est parce que le volume n'est pas un volume TrueCrypt ou si c'est parce que tu as donné une mauvaise clé.

Y'a de la magie sur MacBidouille, j'écris en rouge sans le vouloir ?

Si tu connais un format de fichier qui chiffre mais sans demander de déchiffrer, tu m'intéresses...
Alors bien sûr tu peux uploader un fichier chiffré puis zippé. Mais le DPI, il ne faut pas le prendre pour un con non plus. Ton fichier, il n'arrivera pas à destination. Et les Renseignements Généraux, eux, s'intéresseront à toi.

Ce message a été modifié par chombier - 16 May 2017, 00:52.

[SartMatt]

Accessoirement, comme je l'ai dit plus haut, un fichier chiffré n'a pas nécessairement une en-tête indiquant que c'est un fichier chiffré

Sérieux ? un zip chiffré, mais pas vraiment ?

The extra data header ID for AES encryption is 0x9901

Un zip chiffré à forcément une entête en clair indiquant que c'est un fichier chiffré, parce que le format zip a été défini comme ça. Mais un fichier chiffré n'est pas forcément un zip, et on peut très bien avoir un fichier chiffré ne contenant pas d'entête reconnaisable, parce que l'entête est également chiffrée​. Dans ce cas, seule une personne connaissant le format du fichier et la clé peut reconnaître le fichier. Et le chiffrement entête compris, ça existe déjà. C'est par exemple le cas des volumes TrueCrypt, ils n'ont pas d'entête en clair. Si tu donnes un volume quelconque à TrueCrypt et lui demande de l'ouvrir avec une clé quelconque, il va te jeter, mais en étant techniquement incapable de te dire si c'est parce que le volume n'est pas un volume TrueCrypt ou si c'est parce que tu as donné une mauvaise clé.

Y'a de la magie sur MacBidouille, j'écris en rouge sans le vouloir ?

C'est juste pour attirer ton attention sur ce à quoi tu as répondu sans prendre la peine de lire correctement (ou en faisant exprès de ne pas lire correctement ?) : j'ai dit qu'un fichier chiffré n'a pas forcément d'entête l'indiquant, tu me réponds de façon condescendante pour dire en gros "si si, un zip chiffré est marqué comme tel". Donc réponse à côté de la plaque, un fichier chiffré n'étant pas forcément un zip chiffré...

[chombier]

Accessoirement, comme je l'ai dit plus haut, un fichier chiffré n'a pas nécessairement une en-tête indiquant que c'est un fichier chiffré

Sérieux ? un zip chiffré, mais pas vraiment ?

The extra data header ID for AES encryption is 0x9901

Un zip chiffré à forcément une entête en clair indiquant que c'est un fichier chiffré, parce que le format zip a été défini comme ça. Mais un fichier chiffré n'est pas forcément un zip, et on peut très bien avoir un fichier chiffré ne contenant pas d'entête reconnaisable, parce que l'entête est également chiffrée​. Dans ce cas, seule une personne connaissant le format du fichier et la clé peut reconnaître le fichier. Et le chiffrement entête compris, ça existe déjà. C'est par exemple le cas des volumes TrueCrypt, ils n'ont pas d'entête en clair. Si tu donnes un volume quelconque à TrueCrypt et lui demande de l'ouvrir avec une clé quelconque, il va te jeter, mais en étant techniquement incapable de te dire si c'est parce que le volume n'est pas un volume TrueCrypt ou si c'est parce que tu as donné une mauvaise clé.

Y'a de la magie sur MacBidouille, j'écris en rouge sans le vouloir ?

C'est juste pour attirer ton attention sur ce à quoi tu as répondu sans prendre la peine de lire correctement (ou en faisant exprès de ne pas lire correctement ?) : j'ai dit qu'un fichier chiffré n'a pas forcément d'entête l'indiquant, tu me réponds de façon condescendante pour dire en gros "si si, un zip chiffré est marqué comme tel". Donc réponse à côté de la plaque, un fichier chiffré n'étant pas forcément un zip chiffré...

One minute too late...
Tu as huit heures pour éditer ton message.

[SartMatt]

Si tu connais un format de fichier qui chiffre mais sans demander de déchiffrer, tu m'intéresses...

Nan mais c'est pas possible là, tu fais exprès ou quoi ?

J'ai pas dit qu'il y a des formats de fichiers chiffrés qui demandent pas de déchiffrer, j'ai dit qu'il est possible d'avoir un fichier chiffré qui ne soit pas identifiable comme tel, soit parce qu'il n'a pas d'entête (tiens, prends un fichier texte, chiffre le avec le bon vieux chiffre de César, tu te retrouves avec un fichier chiffré qui n'a pas d'entête... Par exemple, copie ça dans un fichier, et je t'assures que tu auras bel et bien un fichier contenant des données chiffrées mais n'ayant pas d'entête l'indiquant : "MRSPP BONOM OCKB"), soit parce que son entête est également chiffré.

Et je t'ai donné un exemple concret et existant, avec le volume TrueCrypt. Un volume TrueCrypt n'a pas d'entête reconnaissable, il est impossible d'identifier qu'un fichier est un volume TrueCrypt sans connaître la clé de chiffrement.

Le début d'un volume TrueCrypt, c'est 64 octets de sel, donc de données aléatoires non reconnaissables, puis l'entête chiffrée avec ce sel et la clé. Quand tu dis à TrueCrypt d'ouvrir un volume, il prend le mot de passe que tu lui donnes et le sel et les utilise pour générer la clé de déchiffrement de l'en-tête (qui elle même contient la clé des données) et commence à déchiffrer les premiers octets du volume au delà du sel. S'il obtient la chaîne "TRUE" sur les octets 64 à 67, c'est un premier indice que c'est bien un volume TrueCrypt et la bonne clé (mais à ce stade, ce n'est pas encore sûr : statistiquement, en déchiffrant 4 octets avec une clé de n bits, si le résultat est celui attendu, il n'y a qu'une chance sur 2^(n-32) que la clé soit la bonne... donc peanuts quand n >> 32... tu as beaucoup plus de chances qu'une clé quelconque donne TRUE (1/2^32) que de chances qu'une clé quelconque qui donne TRUE soit la bonne...), et il continue alors à déchiffrer le reste de l'entête jusqu'au 512ème octet puis vérifie le checksum d'une partie de cette entête. Si ce checksum est bon, il considère qu'il est bien en présence d'un volume TrueCrypt et que la clé est la bonne. Mais impossible sans la clé de savoir que c'est un volume TrueCrypt, ce ne sont que des données en apparence totalement aléatoires, les seules données non chiffrées étant des données aléatoires. Tu peux même imbriquer dans un volume TrueCrypt un second volume TrueCrypt avec d'autres données, et TrueCrypt ouvrira l'un ou l'autre selon le mot de passe que tu donnes au moment d'ouvrir le volume, tout en étant toujours incapable quand tu ouvres le premier niveau de te dire si un second niveau existe ou non.


Et si tu pousses l'interdiction plus loin en interdisant toutes les données qui "ont l'air d'être chiffrées parce qu'elles ont l'air aléatoires" (seul signe distinctif des données chiffrées sans entête ou avec entête chiffrée), la stéganographie permet de planquer ces données chiffrées dans des données non chiffrées, au prix d'une augmentation du volume. Prends une image bitmap non compressée, dans chaque octet tu peux utiliser le bit de poids faible pour stocker un bit de tes données chiffrées et hop, le volume de données à transférer est multiplié par 8, mais tes données ont désormais l'air d'être une simple image, et non plus des données chiffrées.

Ce message a été modifié par SartMatt - 16 May 2017, 01:30.

[WipeOut]

En même temps quand on regarde ce que Windows 10 ce permet faire, ce brevet est sûrement déjà en route voir déjà appliquer.
Windows 10 a un keylogger intégré si jamais. Mais bon, il paraît c'est pour notre bien à tous.