Key does not have an EFS purpose OID
sryze opened this issue · 7 comments
When trying to decrypt a file via ntfsdecrypt it fails with the following error:
Key does not have an EFS purpose OID
Failed to extract the private RSA key.
I have exported the key from my Windows 10 installation via certmgr (tried different combinations of the checkboxes).
There is also a question on SuperUser related to this error with no solution: https://superuser.com/questions/1632935/ntfsdecrypt-key-does-not-have-an-efs-purpose-oid
ntfsdecrypt v2021.8.22 (libntfs-3g)
The X509 certificates have purpose IDs telling what the certificate can be used for. Among them is EFS encryption.
Did you check the purpose ID of your certificate (PEM or CER format) ? The one I use shows :
386 11: SEQUENCE {
388 3: OBJECT IDENTIFIER keyUsage (2 5 29 15)
393 4: OCTET STRING, encapsulates {
395 2: BIT STRING 4 unused bits
: '1101'B
: }
: }
399 64: SEQUENCE {
401 3: OBJECT IDENTIFIER extKeyUsage (2 5 29 37)
406 57: OCTET STRING, encapsulates {
408 55: SEQUENCE {
410 8: OBJECT IDENTIFIER clientAuth (1 3 6 1 5 5 7 3 2)
420 8: OBJECT IDENTIFIER
: emailProtection (1 3 6 1 5 5 7 3 4)
430 8: OBJECT IDENTIFIER timeStamping (1 3 6 1 5 5 7 3 8)
440 10: OBJECT IDENTIFIER
: encryptedFileSystem (1 3 6 1 4 1 311 10 3 4)
452 11: OBJECT IDENTIFIER '1 3 6 1 4 1 311 10 3 4 1'
: }
: }
: }
When you exported from Windows (pkcs12 format), you did not select "Export all extended properties", and this may be part of the cause (though a certificate with missing properties would fail the signature checking). Showing the properties of your certificate would be useful, at least to make sure you exported the relevant certificate.
Another possibility is that a newer encryption scheme is now used by Windows 10. Three schemes are available in ntfscrypt : DESX, triple DES and AES_256.
Did you check the purpose ID of your certificate (PEM or CER format) ? The one I use shows :
Could you let me know the command that you use to view that info? certutil shows the following for my PFX file:
Certificate Extensions: 3
2.5.29.37: Flags = 0, Length = e
Enhanced Key Usage
Encrypting File System (1.3.6.1.4.1.311.10.3.4)
2.5.29.17: Flags = 0, Length = 1d
Subject Alternative Name
Other Name:
Principal Name=user@PC
2.5.29.19: Flags = 0, Length = 2
Basic Constraints
Subject Type=End Entity
Path Length Constraint=None
openssl:
X509v3 extensions:
X509v3 Extended Key Usage:
Microsoft Encrypted File System
X509v3 Subject Alternative Name:
0....
+.....7.......user@PC.
X509v3 Basic Constraints:
CA:FALSE
...
No Trusted Uses.
No Rejected Uses.
When you exported from Windows (pkcs12 format), you did not select "Export all extended properties" ...
Another possibility is that a newer encryption scheme is now used by Windows 10
Just tried again with that checkbox selected - same result.; also tried using both encryption algorithms presented by the cert manager - Triple DES+SHA1 and AES256 + SHA-256.
I was able to successfully decrypt my files using an older version of ntfsdecrypt coming with Ubuntu 16.04 - ntfsdecrypt v2015.3.14AR.1.
For decoding certificates I use an old "dumpasn1", but the decoding you did shows the expected EFS OID to be present, so the issue must lie elsewhere. This is confirmed by the fact you were able to decrypt your file with an older version.
Since this older version, no significant change has been made to ntfsdecrypt, so the issue must be the fallout of a change in some library. With a live DVD of a recent Debian based distribution, I could locate a difference of behavior in the the TLS function gnutls_x509_crt_get_key_purpose_oid(). According to the documentation the final null char in the OID is not counted, but on my system it is counted.
So, please apply the following patch which take the change into account :
--- ntfsprogs/ntfsdecrypt.c.ref 2021-09-13 09:34:39.000000000 +0200
+++ ntfsprogs/ntfsdecrypt.c 2023-06-19 10:11:24.893099500 +0200
@@ -653,7 +653,7 @@
oid_index,
purpose_oid, &purpose_oid_size, NULL);
if (!err) {
- purpose_oid[purpose_oid_size - 1]
+ purpose_oid[sizeof(oid_size) - 1]
= '\0';
if (!strcmp(purpose_oid,
NTFS_EFS_CERT_PURPOSE_OID_DRF))
Sorry, the proposed patch should be :
--- ntfsprogs/ntfsdecrypt.c.ref 2021-09-13 09:34:39.000000000 +0200
+++ ntfsprogs/ntfsdecrypt.c 2023-06-19 10:11:24.893099500 +0200
@@ -653,7 +653,7 @@
oid_index,
purpose_oid, &purpose_oid_size, NULL);
if (!err) {
- purpose_oid[purpose_oid_size - 1]
+ purpose_oid[sizeof(purpose_oid) - 1]
= '\0';
if (!strcmp(purpose_oid,
NTFS_EFS_CERT_PURPOSE_OID_DRF))
It works with your last proposed patch as well
Fine, so I am closing the issue.