import de certificat de cryptage windows

Le Tue, 20 Mar 2007 17:28:16 +0100, davon a écrit :

bonjour

existe-t-il un moyen d'importer un certificat de cryptage windows (xp en
l'occurence) dans linux, ceci afin de pouvoir utiliser des fichiers cryptés
sous xp indifféremment sous deux systèmes xp et ubuntu se trouvant sur une
même machine ?
ou alors avec quoi faut-il recrypter les fichiers pour que les deux puissent
les lire et garantir un niveau de sécurité au moins aussi élevé que celui
fourni par windows ?

merci

Il me semble que gpg (gnu/linux) et pgp (xindows)sont compatibles.
je n'ai jamais utilisé pgp, gpg marche très bien.
mais peut-être n'ais-je pas compris la question ?

Didier.

didier wrote:

Il me semble que gpg (gnu/linux) et pgp (xindows)sont compatibles.
je n'ai jamais utilisé pgp, gpg marche très bien.
mais peut-être n'ais-je pas compris la question ?

pas tout à fait, des solutions je sais qu'il en existe. merci malgré tout.
simplement je parle de lecture de certificat de cryptage windows, réputé
inviolable puisqu'il cumule AES et les autres.
le hic c'est que tous mes fichiers sont cryptés par un certificat windows et
je voudrais éviter de les décrypter, refaire les partitions et les recrypter
dans un format qui puisse être lu conjointement par linux et windows. bref
je gagnerais énormément de temps à ce que linux puisse lire un certificat de
cryptage windows, mais il est plus que vraisemblable qu'il lui soit
impossible de le faire puisque cet encodage est en quelque sorte un encodage
propriétaire de microsoft.

Dans le message <news:4600195e$0$16070$426a34cc@news.free.fr>,
*davon* tapota sur f.c.o.l.configuration :

pas tout à fait, des solutions je sais qu'il en existe. merci malgré tout.
simplement je parle de lecture de certificat de cryptage windows,

s/cryptage/chiffrage/

réputé inviolable puisqu'il cumule AES et les autres.

Ce sont des certificats X509 standards et que vous pouvez exporter dans un
des formats standards que sont DER, PEM ou PKCS#12.

le hic c'est que tous mes fichiers sont cryptés

s/cryptés/chiffrés/

par un certificat windows et je voudrais éviter de les décrypter,

s/décrypter/déchiffrer/

refaire les partitions et les recrypter

s/recrypter/re-chiffrer/

dans un format qui puisse être lu conjointement par linux et windows.

Le problème c'est le système de fichiers... Je ne crois pas qu'il existe de
drivers NTFS pour Linux qui permettent d'accéder aux fichiers chiffrés par
Windows. Ces fichiers ont le droit, me semble-t-il et d'après mes tests
anciens, à un 'Permission denied' quand on tente d'y accéder.

bref je gagnerais énormément de temps à ce que linux puisse lire un
certificat de cryptage windows,

s/cryptage/chiffrage/

mais il est plus que vraisemblable qu'il lui soit impossible de le faire
puisque cet encodage est en quelque sorte un encodage propriétaire de
microsoft.

Le chiffrement utilisé par Microsoft n'est pas propriétaire puisqu'il
s'appuit sur un standard libre, celui des certificats X509. Ce qui est
propriétaire c'est le système de fichiers.

--
Sébastien Monbrun aka TiChou

On 20 mar, 19:12, Sébastien Monbrun aka TiChou <gro.uohcit@uohcit>
wrote:

dans un format qui puisse être lu conjointement par linux et windows.

Le problème c'est le système de fichiers... Je ne crois pas qu'il
existe de drivers NTFS pour Linux qui permettent d'accéder aux
fichiers chiffrés par Windows. Ces fichiers ont le droit, me
semble-t-il et d'après mes tests anciens, à un 'Permission denied'
quand on tente d'y accéder.

Je suis surpris.

Qu'on ne puisse pas les lire, OK, mais qu'on ne puisse pas y acceder
je trouve ca etonnant.

bref je gagnerais énormément de temps à ce que linux puisse lire un
certificat de cryptage windows,

openssl x509 -text -in certificat-windows

et hop le certificat est lu.

mais il est plus que vraisemblable qu'il lui soit impossible de le faire
puisque cet encodage est en quelque sorte un encodage propriétaire de
microsoft.

Le chiffrement utilisé par Microsoft n'est pas propriétaire puisqu'il
s'appuit sur un standard libre, celui des certificats X509. Ce qui est
propriétaire c'est le système de fichiers.

J'ajoute (corrigez moi si je me trompe).

Un certificat, ca n'est rien d'autre qu'une cle et quelques infos
complementaires.
A partir de la cle on peut deriver pleins de choses. Dont des cles de
session qui peuvent servir a chiffrer, par exemple, une connexion SSL.
Mais on peut s'en servir pour chiffrer un fichier. Mais il faut
savoir comment est chiffré ce fichier et comment est choisi le mode
de chiffrement a partir du certificat. Est ce que microsoft l'a
explique de maniere ouverte? et si oui est ce qu'un developpeur
a pris le temps d'implementer ce systeme?

Il existe pleins de logiciels proprietaires qui se basent sur des
PKI a base de certificats x509. Ce n'est pas parceque le x509 est un
format ouvert que les logiciels l'utilisant le sont aussi.

Dans le message <news:1174469769.906547.4300@l77g2000hsb.googlegroups.com>,
*octane@alinto.com* tapota sur f.c.o.l.configuration :

Le problème c'est le système de fichiers... Je ne crois pas qu'il
existe de drivers NTFS pour Linux qui permettent d'accéder aux
fichiers chiffrés par Windows. Ces fichiers ont le droit, me
semble-t-il et d'après mes tests anciens, à un 'Permission denied'
quand on tente d'y accéder.

Je suis surpris.

Me too.

Qu'on ne puisse pas les lire, OK, mais qu'on ne puisse pas y acceder
je trouve ca etonnant.

C'est le constat que j'avais fait. Les choses ont peut être évoluées. Je
serais ravi qu'on me contredise.

Le chiffrement utilisé par Microsoft n'est pas propriétaire puisqu'il
s'appuit sur un standard libre, celui des certificats X509. Ce qui est
propriétaire c'est le système de fichiers.

J'ajoute (corrigez moi si je me trompe).

Un certificat, ca n'est rien d'autre qu'une cle et quelques infos
complementaires.

Oui, je n'ai pas voulu détailler et mon message précédent peut paraître
ambigu.
Un certificat contient effectivement une clé mais aussi, et cette
information est très importante, le rôle de la clé, à quoi on la destine :
signature, chiffrement de données, authentification, etc.

A partir de la cle on peut deriver pleins de choses. Dont des cles de
session qui peuvent servir a chiffrer, par exemple, une connexion SSL.
Mais on peut s'en servir pour chiffrer un fichier.

Tout dépend du rôle de la clé.

Mais il faut savoir comment est chiffré ce fichier et comment est choisi
le
mode de chiffrement a partir du certificat. Est ce que microsoft l'a
explique de maniere ouverte?

On connaît le principe. Le fichier est chiffré avec une clé symétrique
ordinaire ce qui permet de chiffrer rapidement les données contrairement à
un chiffrement avec un jeu de clés asymétriques. Est ajouté en en-tête du
fichier la clé symétrique préalablement chiffrée avec la clé publique du
certificat de l'utilisateur.

et si oui est ce qu'un developpeur a pris le temps d'implementer ce
systeme?

Je ne crois pas.

Il existe pleins de logiciels proprietaires qui se basent sur des
PKI a base de certificats x509. Ce n'est pas parceque le x509 est un
format ouvert que les logiciels l'utilisant le sont aussi.

Et ici, ce qui est fermé, c'est NTFS et la manière dont sont stockés les
fichiers chiffrés.

--
Sébastien Monbrun aka TiChou

On 21 mar, 14:26, Sébastien Monbrun aka TiChou <gro.uohcit@uohcit>
wrote:

Le problème c'est le système de fichiers... Je ne crois pas qu'il
existe de drivers NTFS pour Linux qui permettent d'accéder aux
fichiers chiffrés par Windows. Ces fichiers ont le droit, me
semble-t-il et d'après mes tests anciens, à un 'Permission denied'
quand on tente d'y accéder.

Je suis surpris.

Me too.

ah (la surprise me force a me gratter le crane, mais je fais confiance

a vos tests)

Qu'on ne puisse pas les lire, OK, mais qu'on ne puisse pas y acceder
je trouve ca etonnant.

C'est le constat que j'avais fait. Les choses ont peut être évoluées. Je
serais ravi qu'on me contredise.

ok

Le chiffrement utilisé par Microsoft n'est pas propriétaire puisqu'il
s'appuit sur un standard libre, celui des certificats X509. Ce qui est
propriétaire c'est le système de fichiers.

J'ajoute (corrigez moi si je me trompe).
Un certificat, ca n'est rien d'autre qu'une cle et quelques infos
complementaires.

Oui, je n'ai pas voulu détailler et mon message précédent peut paraître
ambigu.
Un certificat contient effectivement une clé mais aussi, et cette
information est très importante, le rôle de la clé, à quoi on la destine :
signature, chiffrement de données, authentification, etc.

A partir de la cle on peut deriver pleins de choses. Dont des cles de
session qui peuvent servir a chiffrer, par exemple, une connexion SSL.
Mais on peut s'en servir pour chiffrer un fichier.

Tout dépend du rôle de la clé.

Mais il faut savoir comment est chiffré ce fichier et comment est choisi
le
mode de chiffrement a partir du certificat. Est ce que microsoft l'a
explique de maniere ouverte?

On connaît le principe. Le fichier est chiffré avec une clé symétrique
ordinaire ce qui permet de chiffrer rapidement les données contrairement à
un chiffrement avec un jeu de clés asymétriques. Est ajouté en en-tête du
fichier la clé symétrique préalablement chiffrée avec la clé publique du
certificat de l'utilisateur.

bin c'est la dessus que j'ai du mal. J'ai utilisé un logiciel

propriétaire basé sur la norme x509 qui chiffre des fichiers.
J'ai bien le fichier, j'ai bien le certificat de l'utilisateur,
mais je ne vois pas du tout comment décoder le fichier à l'aide
de, mettons, openssl sur un linux.
Le fichier commence par un entete texte, puis continue par du
binaire. La norme, elle, definit le smime pour encapsuler des
fichiers (ou alors c'est que je l'ai mal lue) et le fichier chiffre
base par ce logiciel proprio n'est pas du tout du smime.

De plus, ce programme permet egalement de chiffrer vers
plusieurs utilisateurs, donc on doit avoir la cle de session
chiffree autant de fois que de destinataires du fichier, et
ca je ne sais pas si ca suit la norme...
C'est pour ca que je disais que le mode de chiffrement peut jouer.
Le principe est connu: la cle va servir a generer une cle de
session qui chiffre le fichier. Mais microsoft a tres bien pu
intercaler un tres grand nombre d'infos que nous n'avons pas
pour dechiffrer tout ca...

et si oui est ce qu'un developpeur a pris le temps d'implementer ce
systeme?

Je ne crois pas.

Il existe pleins de logiciels proprietaires qui se basent sur des
PKI a base de certificats x509. Ce n'est pas parceque le x509 est un
format ouvert que les logiciels l'utilisant le sont aussi.

Et ici, ce qui est fermé, c'est NTFS et la manière dont sont stockés les
fichiers chiffrés.

ok

et puisque j'ai un connaisseur (et j'en profite pour publier sur deux
groupes) est ce que le principe de compte de recouvrement est dans la
norme ou pas?
compte de recouvrement: systematiquement chiffrer les cles de sessions
avec la cle publique d'un compte appele compte de recouvrement. Ceci
afin de pouvoir toujours recupere des infos chiffres par n'importe
quel utilisateur de la PKI.

On Tue, 20 Mar 2007 18:26:50 +0100, "davon" <davon@davantdapres>:

le hic c'est que tous mes fichiers sont cryptés par un certificat windows et
je voudrais éviter de les décrypter, refaire les partitions et les recrypter
dans un format qui puisse être lu conjointement par linux et windows. bref
je gagnerais énormément de temps [...]

Combien de centaines de Go as-tu donc pour que ça prenne tant de
temps ?

Sinon, si tu veux une partition inviolable et portable, cf
<http://www.truecrypt.org/>.