diff --git a/Makefile b/Makefile
index 632bccd4..06b71d3d 100644
--- a/Makefile
+++ b/Makefile
@@ -103,6 +103,7 @@ all:
dssp.go \
dtyp.go \
eerr.go \
+ efsr.go \
epm.go \
even.go \
even6.go \
@@ -117,8 +118,8 @@ all:
lrec.go \
lsad.go \
lsat.go \
- mimicom.go \
mgmt.go \
+ mimicom.go \
mqds.go \
mqmp.go \
mqmq.go \
diff --git a/README.md b/README.md
index 02e240b7..49f0bc2e 100644
--- a/README.md
+++ b/README.md
@@ -296,7 +296,7 @@ Based on the [hirochachacha/go-smb2 fork](https://github.com/oiweiwei/go-smb2.fo
| Spec | Description | Package |
|------|-------------|---------|
-| [MIMICOM](https://gist.github.com/gentilkiwi/e3d9c92b93ed4bb48f7956492c1d335a) | Mimikatz COM Interface | [msrpc/mimicom](./msrpc/mimicom) |
+| [MIMICOM](https://gist.github.com/gentilkiwi/e3d9c92b93ed4bb48f7956492c1d335a) | Mimikatz Command Interface | [msrpc/mimicom](./msrpc/mimicom) |
### Documentation
diff --git a/msdn/.cache/windows_protocols/ms-efsr/00933615-c9cf-4d51-9d9a-bb3fb33a3560 b/msdn/.cache/windows_protocols/ms-efsr/00933615-c9cf-4d51-9d9a-bb3fb33a3560
new file mode 100644
index 00000000..3b05b789
--- /dev/null
+++ b/msdn/.cache/windows_protocols/ms-efsr/00933615-c9cf-4d51-9d9a-bb3fb33a3560
@@ -0,0 +1,66 @@
+ The Encrypted FEK field in the DDF and DRF key list entries MUST consist
+of the following structure, encrypted as specified in the description of the Flags
+field for the key list entry.
+
+
0
|
+
1
|
+
2
|
+
3
|
+
4
|
+
5
|
+
6
|
+
7
|
+
8
|
+
9
|
+ 1
0 |
+
1
|
+
2
|
+
3
|
+
4
|
+
5
|
+
6
|
+
7
|
+
8
|
+
9
|
+ 2
0 |
+
1
|
+
2
|
+
3
|
+
4
|
+
5
|
+
6
|
+
7
|
+
8
|
+
9
|
+ 3
0 |
+
1
|
+
+
+ | Key Length |
+
+
+ | Entropy |
+
+
+ | Algorithm |
+
+
+ | Reserved |
+
+
+ | Key (variable) |
+
+
+ | ... |
+
+
Key Length (4 bytes): The length, in bytes, of
+the Key field. It MUST be a 32-bit unsigned integer in little-endian
+format. Possible values depend on the algorithm ID (ALG_ID) as specified in
+section 2.2.13.<11>
Entropy (4 bytes): The number of bits of true
+randomness in the key contained in this structure. It MUST be a 32-bit unsigned
+integer in little-endian format. Possible values depend on the Algorithm
+as specified in section 2.2.13.
Algorithm (4 bytes): The symmetric
+cryptographic algorithm associated with this key. It MUST be a 32-bit unsigned
+integer in little-endian format. Possible values are specified in section
+2.2.13. The possible values for this field are constrained by the value of the EFS version field in the EFSRPC Metadata.
Reserved (4 bytes): MUST be set to zero and
+ignored.
Key (variable): The FEK for the file.
The EfsRpcDecryptFileSrv method is used to convert an
+existing encrypted object to the unencrypted state in the server's data store.
+-
+
long EfsRpcDecryptFileSrv(
+ [in] handle_t binding_h,
+ [in, string] wchar_t* FileName,
+ [in] unsigned long OpenFlag
+ );
+
binding_h: This is an RPC binding handle parameter,
+as specified in [C706]
+and [MS-RPCE]
+section 2.
FileName: An EFSRPC identifier as specified in
+section 2.2.1.
OpenFlag: This parameter is unused and MUST be
+ignored by the server. It MUST be set to zero by the client.
Return Values: The server MUST return zero if
+it successfully processes the message received from the client. The server MUST
+return a nonzero value if processing fails.
If no object exists on the server with the specified name,
+the server MUST return a nonzero value. If the object exists and is not
+encrypted, the server MUST return success.
Otherwise, the server performs the following actions to
+convert the object in its data store to an unencrypted state:
+If the data object referred to by FileName is a container
+for other objects, the server MUST clear the attribute on the container that
+instructs the data store to encrypt any new objects created in that container.
+The server MAY decrypt encrypted objects that were already in the container
+before this message was received.
+
+Otherwise, the server SHOULD:
+ Check
+that the calling user has access to a private key that will decrypt the file;
+if the user does not have access, return a nonzero value.
+ Decrypt
+the object and discard its EFSRPC
+Metadata.
+
+Return 0 to indicate success.
+
A Marshaled Stream (including the EFSRPC Metadata stream)
+MUST be formatted as follows.
+
+
0
|
+
1
|
+
2
|
+
3
|
+
4
|
+
5
|
+
6
|
+
7
|
+
8
|
+
9
|
+ 1
0 |
+
1
|
+
2
|
+
3
|
+
4
|
+
5
|
+
6
|
+
7
|
+
8
|
+
9
|
+ 2
0 |
+
1
|
+
2
|
+
3
|
+
4
|
+
5
|
+
6
|
+
7
|
+
8
|
+
9
|
+ 3
0 |
+
1
|
+
+
+ | Length |
+
+
+ | 0x4e |
+ 0x00 |
+ 0x54 |
+ 0x00 |
+
+
+ | 0x46 |
+ 0x00 |
+ 0x53 |
+ 0x00 |
+
+
+ | Flag |
+
+
+ | Reserved |
+
+
+ | ... |
+
+
+ | Name Length |
+
+
+ | Stream Name (variable) |
+
+
+ | ... |
+
+
+ | Stream Data Segment 1 (variable) |
+
+
+ | ... |
+
+
+ | Stream Data Segment n (variable) |
+
+
+ | ... |
+
+
Length (4 bytes): The length, in bytes, of
+this stream header from
+the start of this field to the end of the Stream Name field. It MUST be
+a 32-bit unsigned integer in little-endian format.
Flag (4 bytes): This MUST be a 32-bit
+unsigned integer in little-endian format. It MUST be set to 0x00000000 if the
+stream data is encrypted with the FEK. Otherwise, it MUST be
+set to 0x00000001. It MUST always be set to zero in the case of the EFSRPC Metadata stream, and
+ignored by the server in that case.
+-
+
+
+ |
+ Value
+ |
+
+ Meaning
+ |
+
+
+ | 0x00000000 |
+ FEK encryption present |
+
+ | 0x00000001 |
+ FEK encryption not present |
+
+
Reserved (8 bytes): This field MUST be set to
+zero and ignored.
Name Length (4 bytes): The length, in bytes,
+of the Stream Name field. It MUST be a 32-bit unsigned integer in
+little-endian format. This field MUST be set to 0x00000002 for the EFSRPC Metadata stream.
Stream Name (variable): The name of the
+stream. This is set to either a null-terminated Unicode string in UTF-16
+encoding, or an integer value stored in binary form. For the EFSRPC Metadata
+stream, this is always set to 0x1910.
+-
+
+
+ |
+ Value
+ |
+
+ Meaning
+ |
+
+
+ | 0x1910 |
+ EFSRPC Metadata stream |
+
+
Stream Data Segment 1 ... n: These segments MUST contain the
+contents of the stream as well as some metadata for reassembling the segments.
+For encrypted streams, these segments MUST also contain some metadata to aid in
+decryption. They MUST be formatted as specified in section 2.2.3.2.
The Certificate Data structure MUST be formatted as follows.
+
+
0
|
+
1
|
+
2
|
+
3
|
+
4
|
+
5
|
+
6
|
+
7
|
+
8
|
+
9
|
+ 1
0 |
+
1
|
+
2
|
+
3
|
+
4
|
+
5
|
+
6
|
+
7
|
+
8
|
+
9
|
+ 2
0 |
+
1
|
+
2
|
+
3
|
+
4
|
+
5
|
+
6
|
+
7
|
+
8
|
+
9
|
+ 3
0 |
+
1
|
+
+
+ | Offset to Certificate Thumbprint |
+
+
+ | Length of Certificate Thumbprint |
+
+
+ | Offset of Container Name |
+
+
+ | Offset of Provider Name |
+
+
+ | Offset of Display Name |
+
+
+ | Data Fields (variable) |
+
+
+ | ... |
+
+
Offset to Certificate Thumbprint (4 bytes): Offset
+of the Certificate Thumbprint field from the start of this structure. It
+MUST be a 32-bit unsigned integer in little-endian format.
Length of Certificate Thumbprint (4 bytes): The
+length of the Certificate Thumbprint field. It MUST be a 32-bit unsigned
+integer in little-endian format.
Offset of Container Name (4 bytes): Offset of
+the Container Name field (in bytes) from the start of this structure. It
+MUST be a 32-bit unsigned integer in little-endian format. If this field is set
+to zero, then the Container Name field MUST be absent.
Offset of Provider Name (4 bytes): Offset of
+the Provider Name field (in bytes) from the start of this structure. It
+MUST be a 32-bit unsigned integer in little-endian format. If this field is set
+to zero, the Provider Name field MUST be absent. If a Provider Name
+field is present, a Container Name field MUST also be present.
Offset of Display Name (4 bytes): Offset of
+the Display Name field, (in bytes) from the start of this structure. It
+MUST be a 32-bit unsigned integer in little-endian format. If this field is set
+to zero, then the Display Name field MUST be absent.
Data Fields (variable): This field MUST
+contain the following items, in any order, and at the locations indicated by
+the respective Offset fields previously listed. These items MUST be
+completely contained inside this field and MUST NOT overlap each other. There
+MUST NOT be any unused areas within this field that span more than 8 contiguous
+bytes.
+-
+
+
+
0
|
+
1
|
+
2
|
+
3
|
+
4
|
+
5
|
+
6
|
+
7
|
+
8
|
+
9
|
+ 1
0 |
+
1
|
+
2
|
+
3
|
+
4
|
+
5
|
+
6
|
+
7
|
+
8
|
+
9
|
+ 2
0 |
+
1
|
+
2
|
+
3
|
+
4
|
+
5
|
+
6
|
+
7
|
+
8
|
+
9
|
+ 3
0 |
+
1
|
+
+
+ | Certificate Thumbprint (variable) |
+
+
+ | ... |
+
+
+ | Container Name (variable) |
+
+
+ | ... |
+
+
+ | Provider Name (variable) |
+
+
+ | ... |
+
+
+ | Display Name (variable) |
+
+
+ | ... |
+
+
+
+-
+
Certificate Thumbprint
+(variable): The SHA-1 hash of the DER-encoded form of the certificate. For
+more information on SHA-1, see [FIPS180-4]. For more
+information on DER encoding, see [X690].
+
+-
+
Container Name
+(variable): A null-terminated Unicode string in UTF-16 encoding that
+provides a hint as to the public key container in which the key is stored. This
+field MUST always be present if the Provider Name is present. When the Container
+Name field is present, the Offset of Container Name field MUST be
+nonzero; otherwise, this field is ignored by the server and does not affect
+protocol behavior.
+
+-
+
Provider Name (variable):
+A null-terminated Unicode string in UTF-16 encoding. This field MUST always
+be present if the Container Name is present. It MUST be omitted if the Offset
+of Provider Name field is 0; otherwise, this field is ignored by the server
+and does not affect protocol behavior.
+
+-
+
Display Name (variable): A
+null-terminated Unicode string in UTF-16 encoding that provides a hint as to
+the friendly name that can be used to identify this certificate for display
+purposes. This field MUST be omitted if the Offset of Display Name field
+is 0.
+
The EFS_COMPATIBILITY_INFO type is used to represent
+information about the compatibility restrictions of an encrypted file.
+-
+
typedef struct {
+ DWORD EfsVersion;
+ } EFS_COMPATIBILITY_INFO;
+
EfsVersion: The EfsVersion
+associated with the EFSRPC Metadata. Valid values for the EfsVersion
+field are described in sections 2.2.2.1, 2.2.2.2,
+and 2.2.2.3.<29>
The EFS_RPC_BLOB type is used to represent a generic binary large object (BLOB)
+(that is, an opaque data type).
+-
+
typedef struct _EFS_RPC_BLOB {
+ [range(0,266240)] DWORD cbData;
+ [size_is(cbData)] unsigned char* bData;
+ } EFS_RPC_BLOB,
+ *PEFS_RPC_BLOB;
+
cbData: The length, in bytes, of
+the data object in the bData field.
bData: The contents of the data
+object.<25>
The DDF
+and Key List structure in the EFSRPC Metadata MUST be
+formatted as follows.
+
+
0
|
+
1
|
+
2
|
+
3
|
+
4
|
+
5
|
+
6
|
+
7
|
+
8
|
+
9
|
+ 1
0 |
+
1
|
+
2
|
+
3
|
+
4
|
+
5
|
+
6
|
+
7
|
+
8
|
+
9
|
+ 2
0 |
+
1
|
+
2
|
+
3
|
+
4
|
+
5
|
+
6
|
+
7
|
+
8
|
+
9
|
+ 3
0 |
+
1
|
+
+
+ | Length |
+
+
+ | Key_List_1 (variable) |
+
+
+ | ... |
+
+
+ | Key_List_n (variable) |
+
+
+ | ... |
+
+
Length (4 bytes): The number of entries in
+this key list. It MUST
+be a 32-bit unsigned integer in little-endian format.
Key List entries 1 ... n: A number of entries
+equal to the value in the length of key list field. The individual
+entries MUST be formatted as specified in section 2.2.2.1.2.
The EFSX Datum represents the base type for every datum
+within the Version 4 and Version 5 EFSRPC Metadata and MUST be formatted as
+follows.
+
+
0
|
+
1
|
+
2
|
+
3
|
+
4
|
+
5
|
+
6
|
+
7
|
+
8
|
+
9
|
+ 1
0 |
+
1
|
+
2
|
+
3
|
+
4
|
+
5
|
+
6
|
+
7
|
+
8
|
+
9
|
+ 2
0 |
+
1
|
+
2
|
+
3
|
+
4
|
+
5
|
+
6
|
+
7
|
+
8
|
+
9
|
+ 3
0 |
+
1
|
+
+
+ | StructureSize |
+ Role |
+
+
+ | Type |
+ Flags |
+
+
StructureSize (2 bytes): The size in bytes of
+the EFSX Datum. It MUST be a 16-bit unsigned integer in little-endian format.
Role (2 bytes): Specifies the EFSX Datum role.
+It MUST be a 16-bit unsigned integer in little-endian format.
+-
+
+
+ |
+ Value
+ |
+
+ Meaning
+ |
+
+
+ | 0x0000 |
+ The EFSX Datum has no defined role. |
+
+ | 0x0001 |
+ The EFSX Datum contains a reference to a user's certificate store. This reference could be, for example, a certificate hash or the public key from a certificate. |
+
+ | 0x0002 |
+ The EFSX Datum contains data specific to a protector type. See section 2.2.2.2.5 for valid protector types and their associated protector data format. |
+
+ | 0x0003 |
+ The EFSX Datum contains information that is suitable for user display. For example, this could be the user name associated with a protector. |
+
+ | 0x0004 |
+ The EFSX Datum contains information that identifies a private key container. |
+
+ | 0x0005 |
+ The EFSX Datum contains information that identifies the provider name of a CSP or KSP. |
+
+ | 0x0006 |
+ The EFSX Datum contains a user SID. |
+
+ | 0x0007 |
+ The EFSX Datum contains the encrypted File Master Key (FMK). |
+
+ | 0x0008 |
+ The EFSX Datum contains a user's public key. |
+
+ | 0x0009 |
+ The EFSX Datum contains an ephemeral public key. |
+
+ | 0x000a |
+ The EFSX Datum contains the encrypted File Encryption Key (FEK). |
+
+ | 0x000b |
+ The EFSX Datum contains the file Initialization Vector (IV). |
+
+ | 0x000c |
+ The EFSX Datum contains a protector descriptor string.<15> This datum role MUST only be used when EFS_VERSION is 5. |
+
+
Type (2 bytes): Specifies the EFSX Datum type.
+It MUST be a 16-bit unsigned integer in little-endian format.
+-
+
+
+ |
+ Value
+ |
+
+ Meaning
+ |
+
+
+ | Reserved 0x0000 |
+ Reserved. Local use only. |
+
+ | EFSX_TYPE_BLOB 0x0001 |
+ The EFSX Datum MUST be formatted as specified in section 2.2.2.2.3. |
+
+ | EFSX_TYPE_DESCRIPTOR 0x0002 |
+ The EFSX Datum MUST be formatted as specified in section 2.2.2.2.4. |
+
+ | EFSX_TYPE_KEY_PROTECTOR 0x0003 |
+ The EFSX Datum MUST be formatted as specified in section 2.2.2.2.5. |
+
+ | EFSX_TYPE_PROTECTOR_INFO 0x0004 |
+ The EFSX Datum MUST be formatted as specified in section 2.2.2.2.6. |
+
+ | EFSX_TYPE_KEY_AGMT_DATA 0x0005 |
+ The EFSX Datum MUST be formatted as specified in section 2.2.2.2.7. |
+
+ | EFSX_TYPE_FEK_INFO 0x0006 |
+ The EFSX Datum MUST be formatted as specified in section 2.2.2.2.8. |
+
+ | EFSX_TYPE_DPAPI_NG_DATA 0x0007 |
+ The EFSX Datum MUST be formatted as specified in section 2.2.2.2.9. This type MUST only be used when EFS_VERSION is 5.<16> |
+
+
Flags (2 bytes): Specifies datum flags. It
+MUST be a 16-bit unsigned integer in little-endian format. The value of this
+field MUST be zero (0x0000) or a union of one or more of the following values.
+-
+
+
+ |
+ Value
+ |
+
+ Meaning
+ |
+
+
+ | 0x0001 |
+ The EFSX Datum is nested inside a parent structure. |
+
+ | 0x0002 |
+ The EFSX Datum is a complex datum containing nested datum structures. |
+
+
The EFS_HASH_BLOB type is used to represent an X.509 certificate hash.
+-
+
typedef struct _EFS_HASH_BLOB {
+ [range(0, 100)] DWORD cbData;
+ [size_is(cbData)] unsigned char* bData;
+ } EFS_HASH_BLOB;
+
cbData: The number of bytes in the
+bData buffer.
bData: The SHA-1 hash of an X.509
+certificate. For more information on SHA-1, see [FIPS180-4].<22>
The Descriptor Datum encapsulates a Unicode string in
+UTF-16 encoding. It MUST be formatted as below.
+
+
0
|
+
1
|
+
2
|
+
3
|
+
4
|
+
5
|
+
6
|
+
7
|
+
8
|
+
9
|
+ 1
0 |
+
1
|
+
2
|
+
3
|
+
4
|
+
5
|
+
6
|
+
7
|
+
8
|
+
9
|
+ 2
0 |
+
1
|
+
2
|
+
3
|
+
4
|
+
5
|
+
6
|
+
7
|
+
8
|
+
9
|
+ 3
0 |
+
1
|
+
+
+ | EFSX_Datum |
+
+
+ | ... |
+
+
+ | Descriptor_Text (variable) |
+
+
+ | ... |
+
+
EFSX_Datum (8 bytes): MUST be formatted as
+specified in section 2.2.2.2.2.
+The datum Type MUST be EFSX_TYPE_DESCRIPTOR (0x0002). The datum Flags
+MUST NOT include 0x0002.
Descriptor_Text (variable): Contains a
+null-terminated, variable-sized Unicode string in UTF-16 encoding. The Descriptor_Text
+MUST be entirely contained within the Descriptor Datum. The length of
+the Descriptor_Text MUST be at least 2 bytes to include the null
+terminator (0x0000).
The ENCRYPTION_CERTIFICATE_HASH_LIST type is used to
+represent a set of certificate
+hashes.
+-
+
typedef struct _ENCRYPTION_CERTIFICATE_HASH_LIST {
+ [range(0,500)] DWORD nCert_Hash;
+ [size_is(nCert_Hash,)] ENCRYPTION_CERTIFICATE_HASH** Users;
+ } ENCRYPTION_CERTIFICATE_HASH_LIST;
+
nCert_Hash: The number of
+certificate hashes in the list.
Users: A pointer to an array of
+pointers to ENCRYPTION_CERTIFICATE_HASH
+(2.2.10) structures. This array is of size nCert_Hash.<24>
The EfsRpcRemoveUsersFromFile method is used to revoke a user's
+access to an encrypted object. This method revokes the ability of the private key corresponding
+to a given X.509 certificate to decrypt the
+object.
+-
+
DWORD EfsRpcRemoveUsersFromFile(
+ [in] handle_t binding_h,
+ [in, string] wchar_t* FileName,
+ [in] ENCRYPTION_CERTIFICATE_HASH_LIST* Users
+ );
+
binding_h: This is an RPC binding handle parameter,
+as specified in [C706]
+and [MS-RPCE]
+section 2.
FileName: An EFSRPC identifier as specified in
+section 2.2.1.
Users: A list of certificate hashes,
+represented by an ENCRYPTION_CERTIFICATE_HASH_LIST
+structure, whose access is to be removed.
Return Values: The server MUST return 0 if it
+successfully processes the message received from the client. The server MUST
+return a nonzero value if processing fails.
+-
+
If no object exists on the server with the specified
+name, or if the object exists and is not encrypted, the server MUST return a
+nonzero value. The server SHOULD verify that the calling user is authorized to
+access the object, SHOULD verify that the calling user possesses a private key corresponding to a user
+certificate present in the EFSRPC
+Metadata for the object, and MUST return a nonzero value if this
+verification fails. If the calling user is authorized to access the object and
+the set of user certificates on the object contains only one entry, the server
+MUST return a nonzero value.
+
If none of the preceding errors occur, the server MUST
+remove the parts of the object's EFSRPC Metadata that refer to the user
+certificates listed in the Users structure.
On receiving the EfsRpcSetEncryptedFileMetadata method call,
+an EFSRPC server SHOULD ignore the input parameters and return a nonzero value.
+The server MAY choose to act on this method in an implementation-specific
+manner.<58>
+-
+
DWORD EfsRpcSetEncryptedFileMetadata(
+ [in] handle_t binding_h,
+ [in, string, ref] wchar_t* FileName,
+ [in, unique] EFS_RPC_BLOB* OldEfsStreamBlob,
+ [in, ref] EFS_RPC_BLOB* NewEfsStreamBlob,
+ [in, unique] ENCRYPTED_FILE_METADATA_SIGNATURE* NewEfsSignature
+ );
+
binding_h: This is an RPC binding handle parameter,
+as specified in [C706]
+and [MS-RPCE]
+section 2.
FileName: An EFSRPC identifier as specified in
+section 2.2.1.
OldEfsStreamBlob: This parameter SHOULD be set
+to NULL by the client and ignored by the server.<59>
NewEfsStreamBlob: This parameter SHOULD be set
+to a zero-length EFS_RPC_BLOB
+by the client and ignored by the server.<60>
NewEfsSignature: This parameter SHOULD be set
+to NULL by the client and ignored by the server.<61>
Return Values: The server SHOULD return a
+nonzero value.<62>
The ENCRYPTION_CERTIFICATE_HASH type is used to represent a
+single certificate hash.
+For more information on certificates, see [X509].
+-
+
typedef struct _ENCRYPTION_CERTIFICATE_HASH {
+ DWORD cbTotalLength;
+ RPC_SID* UserSid;
+ EFS_HASH_BLOB* Hash;
+ [string] wchar_t* lpDisplayInformation;
+ } ENCRYPTION_CERTIFICATE_HASH;
+
cbTotalLength: The length, in
+bytes, of the structure.
UserSid: The SID of the user who owns
+the certificate. This is intended only as a hint. It MAY be set to zero if no
+such hint is available. The structure of an RPC SID is specified in [MS-DTYP],
+section 2.4.2.3.
Hash: A pointer to an EFS_HASH_BLOB (2.2.7)
+structure.
lpDisplayInformation: A string that
+contains the subject or principal name of the account the certification is
+assigned to. The subject name and the principal name can be the same. This is
+only intended as a hint for display purposes, and is implementation-dependent.
+This field MAY be set to NULL if no such information is available.
On receiving the EfsRpcNotSupported method call, an EFSRPC
+server SHOULD implement the EfsRpcNotSupported method as specified in this
+section and return a nonzero value. However, a server MAY<44> choose to interpret and respond
+to the arguments as specified in section 3.1.4.2.13.
+-
+
DWORD EfsRpcNotSupported(
+ [in] handle_t binding_h,
+ [in, string] wchar_t* Reserved1,
+ [in, string] wchar_t* Reserved2,
+ [in] DWORD dwReserved1,
+ [in] DWORD dwReserved2,
+ [in, unique] EFS_RPC_BLOB* Reserved,
+ [in] BOOL bReserved
+ );
+
binding_h: This is an RPC binding handle parameter,
+as specified, in [C706]
+and in [MS-RPCE]
+section 2.
+
Reserved1: This parameter is not used. It MUST
+be set to an empty string by the client and ignored by the server.
Reserved2: This parameter is not used. It MUST
+be set to an empty string by the client and ignored by the server.
dwReserved1: This parameter is not used. It
+MUST be set to zero by the client and ignored by the server.
dwReserved2: This parameter is not used. It
+MUST be set to zero by the client and ignored by the server.
Reserved: This parameter is not used. It MUST
+be set to NULL by the client and ignored by the server.
bReserved: This parameter is not used. It MUST
+be set to FALSE by the client and ignored by the server.
Return Values: The EFSRPC server SHOULD return
+a nonzero value. However, the server MAY<45> process
+this as described in section 3.1.4.2.13.
The Encrypting File System Remote Protocol (hereafter
+referred to as EFSRPC) is a Remote
+Procedure Call (RPC) interface that is used to manage data objects stored
+in an encrypted form. The objective of encrypting data in this fashion is to
+enforce access control policies and to provide confidentiality from
+unauthorized users.
EFSRPC is implemented in Windows to provide remote
+management for files
+encrypted by the Encrypting
+File System (EFS). EFS is the ability of the New Technology File System
+(NTFS) file system to encrypt files on disk in a manner that is transparent
+to the user. For more information on EFS, see [MSFT-EFS]. For more
+information about NTFS,
+see [MSFT-NTFS].
EFSRPC does not address how data is encrypted, how the
+encrypted data is stored, or how it is accessed for routine operations such as
+reading, writing, creating, and deleting. All these actions are specific to the
+server implementation. On Windows, NTFS provides the storage mechanism (the
+file is the unit of storage) and the Server Message Block (SMB) Protocol
+provides remote access to such files. For more information about SMB, see [MS-SMB]
+and [MS-SMB2].
EFSRPC models the underlying data encryption architecture
+using two basic constructs:
+A set of data objects, each of which is encrypted independently and
+can be managed independently.
+
+A set of access control subjects, each of which is represented by
+a key pair generated by a public
+key cryptographic algorithm. The public key of this key pair is embedded in
+a certificate and can be
+widely distributed in that form. The corresponding private key is held solely
+by the user or users who represent that subject. Thus, a given access control
+subject can correspond to one or more users, and a given user can possess the
+private keys for zero or more access control subjects. Access control subjects
+are further divided into two types:
+ Unprivileged
+user subjects, which are used for routine data access by ordinary users of the
+system. For convenience, this specification refers to such subjects as user
+certificate.
+ Data Recovery Agents (DRAs),
+which are controlled by system administrators. The storage system ensures that
+all active DRAs for the system are automatically authorized to access all
+encrypted objects on the system. If an unprivileged user loses the private key,
+an administrator can use a DRA's private key to recover the contents of
+encrypted objects.
+
EFSRPC also assumes that each encrypted object is associated
+with some security-related metadata, which contains information required for
+authorized users and DRAs to access the plaintext of the object.
+This specification refers to this security-related metadata as the EFSRPC Metadata.
EFSRPC does not specify how data is encrypted, stored, or
+accessed. It is possible to build a compliant EFSRPC implementation that uses a
+mechanism, such as access
+control lists (ACLs), instead of encryption to control access to data
+objects. For the purposes of this specification, the term encrypted is used to
+indicate that a data object and its metadata can be successfully manipulated
+through the EFSRPC methods, with the exception of the EfsRpcEncryptFileSrv
+method, which converts data objects from an unencrypted state to an encrypted
+state.
Within the preceding model, EFSRPC provides various
+categories of management routines. The syntax of the individual methods and
+rules for how these methods are processed on the server are specified in
+section 3.1.4.2. The
+categories of management routines that EFSRPC provides are as follows:
+Requesting the server to convert objects from encrypted state to
+unencrypted state and vice versa.
+
+Creating, querying, and manipulating the EFSRPC Metadata. Clients
+use the following methods to query and change which user certificates can be
+used to decrypt an encrypted object. The set of user certificates with access
+to an object needs to be changed when the set of users with access to the
+object changes or when a user with access to the object changes the user
+certificate. The following methods can also be used to copy the access rights
+from one object to another; the EfsRpcDuplicateEncryptionInfoFile
+method is particularly well-suited for this purpose. Methods:
+
+Performing backup of encrypted objects in ciphertext form along
+with their EFSRPC Metadata, and restoring encrypted objects from such backups. Depending
+on the implementation of these methods, the backups that are created can expose
+the implementation-specific EFSRPC Metadata format to the client. The Windows
+implementation of these methods exposes the Windows EFSRPC Metadata format;
+however, Windows applications do not manipulate this information. The following
+methods are suitable for secure content archival or transferring encrypted data
+securely between servers of the same implementation because they do not require
+decrypting the data. Methods:
+
+Controlling the server's encryption subsystem. Methods:
+
Most of the EFSRPC routines are stateless and can be called
+in any order. When one of these routines is called, the message exchange is as
+follows.
Figure 1: Message exchange for stateless routines
There are two routines in EFSRPC that are an exception to
+the stateless nature of the protocol. Several methods, collectively known as
+the EFSRPC raw methods, are an exception and need to be called in a specific
+order. This includes the EfsRpcOpenFileRaw, EfsRpcReadFileRaw,
+EfsRpcWriteFileRaw, and EfsRpcCloseRaw methods. The following two sequences are
+permissible.
Figure 2: Message sequence for opening a file
Figure 3: Message sequence for importing a file
The EFS_KEY_INFO type is used to represent information about
+a key of a symmetric
+cryptosystem.
+-
+
typedef struct {
+ DWORD dwVersion;
+ unsigned long Entropy;
+ ALG_ID Algorithm;
+ unsigned long KeyLength;
+ } EFS_KEY_INFO;
+
dwVersion: The version of this data
+structure. It MUST be equal to 0x00000001.
Entropy: The actual number of bits
+of entropy or true randomness in the key. This value, divided by 8, MUST be
+less than or equal to the value of the KeyLength member.
Algorithm: The cryptographic
+algorithm with which the key is intended to be used.
KeyLength: The total length, in
+bytes, of the key. This value, multiplied by 8, MUST be greater than or equal
+to the value of the Entropy member. Valid combinations of Entropy,
+Algorithm, and KeyLength are specified in section 2.2.13.
The Protector Info Datum encapsulates information
+describing the origin of a protector. It MUST be formatted as below.
+
+
0
|
+
1
|
+
2
|
+
3
|
+
4
|
+
5
|
+
6
|
+
7
|
+
8
|
+
9
|
+ 1
0 |
+
1
|
+
2
|
+
3
|
+
4
|
+
5
|
+
6
|
+
7
|
+
8
|
+
9
|
+ 2
0 |
+
1
|
+
2
|
+
3
|
+
4
|
+
5
|
+
6
|
+
7
|
+
8
|
+
9
|
+ 3
0 |
+
1
|
+
+
+ | EFSX_Datum |
+
+
+ | ... |
+
+
+ | Data_Fields (variable) |
+
+
+ | ... |
+
+
EFSX_Datum (8 bytes): MUST be formatted as
+specified in section 2.2.2.2.2.
+The datum Type MUST be EFSX_TYPE_PROTECTOR_INFO (0x0004). The datum Flags
+SHOULD include 0x0002 indicating a complex datum.
Data_Fields (variable): This field contains
+any number of nested EFSX_Datum structures. The nested datum structures MUST
+NOT overlap, and MUST be entirely contained within the protector info datum.
The ENCRYPTED_FILE_METADATA_SIGNATURE structure is used by
+the client to prove to the server that it possesses a private key that is
+authorized to decrypt a given object.
+-
+
typedef struct _ENCRYPTED_FILE_METADATA_SIGNATURE {
+ DWORD dwEfsAccessType;
+ ENCRYPTION_CERTIFICATE_HASH_LIST* CertificatesAdded;
+ ENCRYPTION_CERTIFICATE* EncryptionCertificate;
+ EFS_RPC_BLOB* EfsStreamSignature;
+ } ENCRYPTED_FILE_METADATA_SIGNATURE;
+
dwEfsAccessType: The operation
+being performed. It MUST be set to one of the following values.
+-
+
+
+ |
+ Value
+ |
+
+ Meaning
+ |
+
+
+ | EFS_METADATA_ADD_USER 0x00000001 |
+ One or more additional user certificates are being granted access to the object. |
+
+ | EFS_METADATA_REMOVE_USER 0x00000002 |
+ One or more user certificates are having their access to the object revoked. |
+
+ | EFS_METADATA_REPLACE_USER 0x00000004 |
+ One or more user certificates with access to the object are being replaced. |
+
+ | EFS_METADATA_GENERAL_OP 0x00000008 |
+ A change is being made to the metadata that is not fully described by exactly one of the previous options. |
+
+
CertificatesAdded: The X.509 certificates whose
+corresponding private keys are to be granted or denied the ability to decrypt
+the object.
EncryptionCertificate: The X.509
+certificates whose corresponding private key the caller claims to possess.
EfsStreamSignature: The signature
+obtained by signing the SHA-1 hash of the new EFSRPC Metadata with the
+private RSA key
+corresponding to EncryptionCertificate.
Each stream data segment MUST be formatted as follows.
+
+
0
|
+
1
|
+
2
|
+
3
|
+
4
|
+
5
|
+
6
|
+
7
|
+
8
|
+
9
|
+ 1
0 |
+
1
|
+
2
|
+
3
|
+
4
|
+
5
|
+
6
|
+
7
|
+
8
|
+
9
|
+ 2
0 |
+
1
|
+
2
|
+
3
|
+
4
|
+
5
|
+
6
|
+
7
|
+
8
|
+
9
|
+ 3
0 |
+
1
|
+
+
+ | Length |
+
+
+ | 0x47 |
+ 0x00 |
+ 0x55 |
+ 0x00 |
+
+
+ | 0x52 |
+ 0x00 |
+ 0x45 |
+ 0x00 |
+
+
+ | Reserved |
+
+
+ | Data Segment Encryption Header (variable) |
+
+
+ | ... |
+
+
+ | Stream Data (variable) |
+
+
+ | ... |
+
+
Length (4 bytes): The length, in bytes, of
+this segment. It MUST be a 32-bit unsigned integer in little-endian format. The
+length MUST be measured from the start of this field to the end of the Stream
+Data field.
Reserved (4 bytes): This field is set to zero
+and is ignored by the server.
Data Segment Encryption Header (variable): This
+header MUST be present only if the stream is encrypted (that
+is, if the Flag field in the stream header is set to zero and this is
+not the EFSRPC Metadata stream). It MUST be formatted as specified in section 2.2.3.3.
Stream Data (variable): This field MUST
+contain part or all of the stream data. If the Data Segment Encryption
+Header field is present, Stream Data MUST be consistent with it. Stream
+Data MUST consist of contiguous bytes taken from the stream except for zero
+bytes that are omitted in accordance with the Data Segment Encryption Header.
+If the stream is encrypted, its data MUST be encrypted with the FEK, using the algorithm
+indicated by the Algorithm field in the EFSRPC Metadata (specified
+in section 2.2.2) in the Cipher Block Chaining (CBC) mode.
On receiving the EfsRpcGetEncryptedFileMetadata method call,
+an EFSRPC server SHOULD ignore the input parameters and return a nonzero value.
+The server MAY choose to act on this method in an implementation-specific
+manner.<55>
+-
+
DWORD EfsRpcGetEncryptedFileMetadata(
+ [in] handle_t binding_h,
+ [in, string, ref] wchar_t* FileName,
+ [out, ref] EFS_RPC_BLOB** EfsStreamBlob
+ );
+
binding_h: This is an RPC binding handle parameter,
+as specified in [C706]
+and [MS-RPCE]
+section 2.
FileName: An EFSRPC identifier, as specified
+in section 2.2.1.
EfsStreamBlob: The server SHOULD ignore this
+parameter.<56>
Return Values: The server SHOULD return a
+nonzero value.<57>
+
+
0
|
+
1
|
+
2
|
+
3
|
+
4
|
+
5
|
+
6
|
+
7
|
+
8
|
+
9
|
+ 1
0 |
+
1
|
+
2
|
+
3
|
+
4
|
+
5
|
+
6
|
+
7
|
+
8
|
+
9
|
+ 2
0 |
+
1
|
+
2
|
+
3
|
+
4
|
+
5
|
+
6
|
+
7
|
+
8
|
+
9
|
+ 3
0 |
+
1
|
+
+
+ | Length |
+
+
+ | Reserved1 |
+
+
+ | EFS_Version |
+
+
+ | Reserved2 |
+
+
+ | EFS_ID (16 bytes) |
+
+
+ | ... |
+
+
+ | ... |
+
+
+ | ... |
+
+
+ | EFS_Hash (16 bytes) |
+
+
+ | ... |
+
+
+ | ... |
+
+
+ | ... |
+
+
+ | Reserved3 (16 bytes) |
+
+
+ | ... |
+
+
+ | ... |
+
+
+ | ... |
+
+
+ | DDF_Offset |
+
+
+ | DRF_Offset |
+
+
+ | Reserved4 |
+
+
+ | ... |
+
+
+ | ... |
+
+
+ | Data_Fields (variable) |
+
+
+ | ... |
+
+
Length (4 bytes): This field MUST contain a 32-bit
+unsigned integer equal to the length, in bytes, of the EFSRPC Metadata.<7>
Reserved1 (4 bytes): MUST be set to zero and
+ignored upon receipt.
EFS_Version (4 bytes): This field represents
+the highest EFS version
+supported by the implementation that created this metadata. It MUST be a 32-bit
+unsigned integer in little-endian format. It MUST be set to one of the
+following values.
+-
+
+
+ |
+ Value
+ |
+
+ Meaning
+ |
+
+
+ | Version_1 0x00000001 |
+ The file encryption key (FEK) will be a DESX key, and encrypted with RSA only. The Flags field in all key list entries will be zero. |
+
+ | Version_2 0x00000002 |
+ The FEK will use DESX, 3DES, or AES-256. The FEK will be encrypted with RSA only. The Flags field in all key list entries will be zero. |
+
+ | Version_3 0x00000003 |
+ The FEK will use DESX, 3DES, or AES-256. The FEK will be encrypted with either RSA or AES-256. |
+
+
A server that supports a given version number MUST also
+support all lower numbered versions. A server SHOULD support all versions
+listed.<8>
Reserved2 (4 bytes): MUST be set to zero and
+ignored upon receipt.
EFS_ID (16 bytes): A 16-byte GUID value that MUST be
+unique for the computer that created this metadata.
EFS_Hash (16 bytes): This field SHOULD be set
+to zero and ignored by the server.<9>
Reserved3 (16 bytes): MUST be set to zero and
+ignored upon receipt.
DDF_Offset (4 bytes): This field MUST contain
+the offset, in bytes, of the data
+decryption field (DDF) key list from the start of the EFSRPC Metadata. It
+MUST be a 32-bit unsigned integer in little-endian format. The DDF key list
+lies completely within the Data Fields and does not overlap the data recovery field (DRF)
+key list (if present).
DRF_Offset (4 bytes): This field MUST contain
+the offset, in bytes, of the DRF key list from the start of the EFSRPC
+Metadata. It MUST be a 32-bit unsigned integer in little-endian format. A zero
+value in this field indicates that the DRF key list is absent and no DRAs have been applied to
+the file. If present,
+the DRF key list MUST lie completely within Data Fields and MUST NOT
+overlap the DDF key list.
Reserved4 (12 bytes): MUST be set to zero and
+ignored upon receipt.
Data_Fields (variable): This field MUST
+contain the following two items in any order at the locations indicated by the
+respective Offset fields previously listed. Both items MUST conform to the key
+list format specified in section 2.2.2.1.1. The DDF key
+list MUST NOT overlap with the DRF key list (if present). There MUST NOT be any
+unused areas within this field spanning more than 8 contiguous bytes. Any
+unused areas within this field MUST be set to zero bytes and ignored by the
+server.
+-
+
+
+
0
|
+
1
|
+
2
|
+
3
|
+
4
|
+
5
|
+
6
|
+
7
|
+
8
|
+
9
|
+ 1
0 |
+
1
|
+
2
|
+
3
|
+
4
|
+
5
|
+
6
|
+
7
|
+
8
|
+
9
|
+ 2
0 |
+
1
|
+
2
|
+
3
|
+
4
|
+
5
|
+
6
|
+
7
|
+
8
|
+
9
|
+ 3
0 |
+
1
|
+
+
+ | DDF_key_list (variable) |
+
+
+ | ... |
+
+
+ | DRF_key_list (variable) |
+
+
+ | ... |
+
+
+
+-
+
DDF_key_list (variable): This
+field MUST contain one or more entries. Each entry consists of the file's FEK,
+encrypted with the public
+key of a user authorized to access the file.
+
+-
+
DRF_key_list (variable): This
+MUST contain one or more entries. Each entry consists of the file’s FEK,
+encrypted with the public key of a DRA authorized to access the file. This MUST
+only be present if the value in the DRF offset field is nonzero.
+
The EfsRpcFileKeyInfo method is used to query and modify
+information about the keys
+used to encrypt a given object.
+-
+
DWORD EfsRpcFileKeyInfo(
+ [in] handle_t binding_h,
+ [in, string] wchar_t* FileName,
+ [in] DWORD InfoClass,
+ [out] EFS_RPC_BLOB** KeyInfo
+ );
+
binding_h: This is an RPC binding handle parameter,
+as specified in [C706]
+and [MS-RPCE]
+section 2.
FileName: An EFSRPC identifier, as specified
+in section 2.2.1.
InfoClass: One of the values in the following
+table. With the exception of UPDATE_KEY_USED (0x00000100), a server SHOULD
+support all of these values. A server MAY choose to support UPDATE_KEY_USED.<46>
+-
+
+
+ |
+ Value
+ |
+
+ Meaning
+ |
+
+
+ | BASIC_KEY_INFO 0x00000001 |
+ Request information about the keys used to encrypt the object's contents. On success, the server will return the information in an EFS_KEY_INFO (2.2.14)structure in the KeyInfo parameter. |
+
+ | CHECK_COMPATIBILITY_INFO 0x00000002 |
+ Requests the EfsVersion for the encrypted file. On success, the server will return the information in an EFS_COMPATIBILITY_INFO structure in the KeyInfo parameter. |
+
+ | UPDATE_KEY_USED 0x00000100 |
+ Update the user certificates used to give a specific user access to an object. The server will populate the KeyInfo parameter with a zero-terminated, wide character Unicode string that contains a newline-separated list of names of objects successfully updated. |
+
+ | CHECK_DECRYPTION_STATUS 0x00000200 |
+ Request a hint from the server as to whether the given object could be successfully decrypted without further user intervention or higher-level events. The server will return this information in an EFS_DECRYPTION_STATUS_INFO structure in the KeyInfo parameter. |
+
+ | CHECK_ENCRYPTION_STATUS 0x00000400 |
+ Request a hint from the server as to whether the given object could be successfully encrypted without further user intervention or higher-level events. The server will return this information in an EFS_ENCRYPTION_STATUS_INFO structure in the KeyInfo parameter. |
+
+
KeyInfo: Returned by the server, as previously
+specified.
Return Values: The server MUST return 0 if it
+successfully processes the message received from the client. The server MUST
+return a nonzero value if processing fails.
+-
+
If no object exists on the server with the specified
+name the server MUST return a nonzero value.
+
+-
+
If the InfoClass parameter is not equal to
+CHECK_ENCRYPTION_STATUS and the object with the specified name is not
+encrypted, the server MUST return a nonzero value.
+
+-
+
If the value in the InfoClass parameter is
+unsupported by the server, the server MUST return a nonzero value.
+
+-
+
If the value in the InfoClass parameter is
+equal to BASIC_KEY_INFO, the server SHOULD read the EFSRPC Metadata of the
+object referred to by the FileName argument and return information about its FEK in an EFS_KEY_INFO
+structure within the KeyInfo argument.
+
+-
+
If the value in the InfoClass parameter is
+equal to UPDATE_KEY_USED, the implementation supports this value, and the FileName
+parameter does not satisfy the implementation-specific requirements for this
+operation<47>, the server MUST return a
+nonzero value.
+
+-
+
If the value in the InfoClass parameter is
+equal to UPDATE_KEY_USED, the implementation supports this value, and the FileName
+parameter does satisfy all implementation-specific requirements, the server
+MUST update the EFSRPC Metadata of all the data objects referred by FileName
+in an implementation-specific way<48>, and
+return a newline-separated list of EFSRPC Identifiers thus updated in the KeyInfo
+parameter.
+
+-
+
If the value in the InfoClass parameter is
+equal to CHECK_ENCRYPTION_STATUS, the server MUST return an
+EFS_ENCRYPTION_STATUS_INFO structure in the KeyInfo parameter, which
+provides a hint to the client what error code would be returned if encryption
+was attempted on this object without any further user interaction or
+higher-level events.
+
+-
+
If the value in the InfoClass parameter is
+equal to CHECK_DECRYPTION_STATUS, the server SHOULD return
+ERROR_REQUIRES_INTERACTIVE_WINDOWSTATION ([MS-ERREF]
+section 2.2).
+The server MAY, instead, return an EFS_DECRYPTION_STATUS_INFO structure in the KeyInfo
+parameter, which provides a hint to the client what error code would be
+returned if decryption were attempted on this object without any further user
+interaction or higher-level events.
+
+-
+
If the value of the InfoClass parameter is equal to
+CHECK_COMPATIBILITY_INFO, the server MUST return an EFS_COMPATIBILITY_INFO
+structure in the KeyInfo parameter, which provides the EFSVersion of the EFSRPC
+metadata associated with the file.
+
The Encrypting File System Remote (EFSRPC) Protocol is used
+for performing maintenance and management operations on encrypted data that is
+stored remotely and accessed over a network. It is used in Windows to manage files that reside on remote
+file servers and are encrypted using the Encrypting File System (EFS).
Sections 1.5, 1.8, 1.9, 2, and 3 of this specification are
+normative. All other sections and examples in this specification are
+informative.
Each individual Protector List Entry MUST be formatted as
+follows.
+
+
0
|
+
1
|
+
2
|
+
3
|
+
4
|
+
5
|
+
6
|
+
7
|
+
8
|
+
9
|
+ 1
0 |
+
1
|
+
2
|
+
3
|
+
4
|
+
5
|
+
6
|
+
7
|
+
8
|
+
9
|
+ 2
0 |
+
1
|
+
2
|
+
3
|
+
4
|
+
5
|
+
6
|
+
7
|
+
8
|
+
9
|
+ 3
0 |
+
1
|
+
+
+ | EFSX_Datum |
+
+
+ | ... |
+
+
+ | ProtectorType |
+ ProtectorFlags |
+
+
+ | Data_Fields (variable) |
+
+
+ | ... |
+
+
EFSX_Datum (8 bytes): MUST be formatted as
+specified in section 2.2.2.2.2.
+The datum Type MUST be EFSX_TYPE_KEY_PROTECTOR (0x0003) and SHOULD have
+a Role of EFSX_ROLE_IGNORE (0x0000). The datum Flags SHOULD
+include 0x0002 indicating a complex datum.
ProtectorType (2 bytes): The type of the
+protector. It MUST be a 16-bit unsigned integer in little-endian format.
+Possible values are specified below.
+-
+
+
+ |
+ Value
+ |
+
+ Meaning
+ |
+
+
+ | 0x0001 |
+ The protector was derived from a public/private key pair using a key agreement. The Data Fields SHOULD include an EFSX_Datum of Type EFSX_TYPE_KEY_AGMT_DATA (0x0005) and Role 0x0002. |
+
+ | 0x0002 |
+ The protector was derived from a public/private key pair capable of performing asymmetric encryption. The Data Fields SHOULD include an EFSX_Datum of Type EFSX_TYPE_BLOB (0x0001) and Role 0x0002. |
+
+ | 0x0003 |
+ The protector was derived using a DPAPI-NG encryption provider on the endpoint. The Data Fields SHOULD include an EFSX_Datum of Type EFSX_TYPE_DPAPI_NG_DATA (0x0007) and Role 0x0002. |
+
+
ProtectorFlags (2 bytes): The flags for the
+protector. It MUST be a 16-bit unsigned integer in little-endian format. The
+value MUST be 0x0000 or a union of one or more of the following values.
+-
+
+
+ |
+ Value
+ |
+
+ Meaning
+ |
+
+
+ | 0x0001 |
+ The protector is a legacy protector, and stores the Encrypted FEK as specified in section 2.2.2.1.5. |
+
+ | 0x0002 |
+ If this is a legacy protector (flag 0x0001 is also set), the Encrypted FEK is encrypted using AES 256, with a key that is obtained by signing the non-terminated Unicode string "MICROSOFTE" (20 bytes long) with the user's RSA and computing the SHA-256 hash of the result. |
+
+ | 0x0004 |
+ If this bit is set, bit 0x0001 MUST also be set to indicate a legacy protector. This bit indicates that the legacy protector stores the File Master Key (FMK) encrypted in the Encrypted FEK structure instead of the File Encryption Key (FEK). |
+
+
Data_Fields (variable): This field contains
+any number of nested EFSX_Datum structures. The nested datum structures MUST
+NOT overlap and MUST be entirely contained within the protector list entry.
+This field SHOULD contain a datum with a Role of 0x0002 (protector data)
+and a datum with a Type of EFSX_TYPE_PROTECTOR_INFO (0x0004).
The DDF and DRF Protector List structure in the Version 4
+EFSRPC Metadata MUST be formatted as follows.
+
+
0
|
+
1
|
+
2
|
+
3
|
+
4
|
+
5
|
+
6
|
+
7
|
+
8
|
+
9
|
+ 1
0 |
+
1
|
+
2
|
+
3
|
+
4
|
+
5
|
+
6
|
+
7
|
+
8
|
+
9
|
+ 2
0 |
+
1
|
+
2
|
+
3
|
+
4
|
+
5
|
+
6
|
+
7
|
+
8
|
+
9
|
+ 3
0 |
+
1
|
+
+
+ | StructureSize |
+
+
+ | ProtectorsCount |
+ Protector_List_Entries (variable) |
+
+
+ | ... |
+
+
+ | … |
+
+
+ | ... |
+
+
StructureSize (4 bytes): The size in bytes of
+the protector list. It MUST be a 32-bit unsigned integer in little-endian
+format.
ProtectorsCount (2 bytes): This represents
+the number of protectors in the protector list. It MUST be a 16-bit unsigned
+integer in little-endian format.
Protector_List_Entries (variable): A number of
+entries equal to the value in the ProtectorsCount field. The individual entries
+MUST be formatted as specified in section 2.2.2.2.5.
The EFS_DECRYPTION_STATUS_INFO type is used to represent the
+predicted outcome if an attempt were made to read the plaintext of an encrypted
+object.
+-
+
typedef struct {
+ DWORD dwDecryptionError;
+ DWORD dwHashOffset;
+ DWORD cbHash;
+ } EFS_DECRYPTION_STATUS_INFO;
+
dwDecryptionError: The error code
+returned if decryption were attempted. If the operation were to succeed, this
+value MUST be zero. Otherwise it MUST be set to a nonzero value.
dwHashOffset: The offset of the
+appended certificate
+hash in bytes from the start of this structure.
cbHash: The length in bytes of the
+appended certificate hash.
If dwDecryptionError is nonzero, the preceding fields are
+followed by the hash of a certificate whose corresponding private key is required for
+the decryption to succeed.
The Data Segment Encryption Header MUST be formatted as
+follows.
+
+
0
|
+
1
|
+
2
|
+
3
|
+
4
|
+
5
|
+
6
|
+
7
|
+
8
|
+
9
|
+ 1
0 |
+
1
|
+
2
|
+
3
|
+
4
|
+
5
|
+
6
|
+
7
|
+
8
|
+
9
|
+ 2
0 |
+
1
|
+
2
|
+
3
|
+
4
|
+
5
|
+
6
|
+
7
|
+
8
|
+
9
|
+ 3
0 |
+
1
|
+
+
+ | Starting File Offset |
+
+
+ | ... |
+
+
+ | Length |
+
+
+ | Bytes Within Stream Size |
+
+
+ | Bytes Within VDL |
+
+
+ | 0x0000 |
+ Data Unit Shift |
+ Chunk Shift |
+
+
+ | Cluster Shift |
+ 0x01 |
+ Number of Data Blocks |
+
+
+ | Data Block Sizes (variable) |
+
+
+ | ... |
+
+
+ | Extended Header (16 bytes, optional) |
+
+
+ | ... |
+
+
+ | ... |
+
+
+ | ... |
+
+
Starting File Offset (8 bytes): This field
+MUST contain an unsigned 64-bit integer in little-endian format denoting the
+offset, in bytes, into the stream being serialized of the first data byte
+contained in this data segment.
Length (4 bytes): The length of this header,
+in bytes, measured from the beginning of the Starting File Offset field
+to the end of the Data Segment Encryption Header. It MUST be a 32-bit
+unsigned integer in little-endian format. Any unused bytes within this
+structure MUST be set to zero and ignored by the server.
Bytes Within Stream Size (4 bytes): The number
+of bytes contained within this stream data segment that fall within the stream
+size. It MUST be a 32-bit unsigned integer in little-endian format. This can be
+less than the number of bytes actually present due to padding required by the
+encryption algorithm.
Bytes Within VDL (4 bytes): The number of
+bytes contained within this stream data segment that fall within the valid data length (VDL). It
+MUST be a 32-bit unsigned integer in little-endian format. This can be less
+than the number of bytes actually present due to padding required by the
+encryption algorithm. Bytes beyond the VDL MUST be set to zero after
+decryption.
Data Unit Shift (1 byte): The base-2 logarithm
+of the data unit size. It MUST be an 8-bit unsigned integer. For files that are
+not sparse files, the
+data unit size MUST be set to the size of the data in this segment. For sparse
+files, it MUST be equal to the size of a compression unit, which is the
+smallest unit that all holes MUST be a multiple of.
Chunk Shift (1 byte): The base-2 logarithm of
+the chunk size. It MUST be an 8-bit unsigned integer. The chunk size MUST be
+equal to the data unit size.
Cluster Shift (1 byte): The base-2 logarithm
+of the cluster size in bytes. It MUST be an 8-bit unsigned integer. It MUST be
+equal to the smallest unit of allocation in the underlying file system.
Number of Data Blocks (2 bytes): This field
+MUST contain the number of data blocks specified in this segment. It MUST be a
+16-bit unsigned integer in little-endian format. It MUST be equal to the number
+of entries in the Data Block Sizes field specified next.
Data Block Sizes (variable): This field MUST
+consist of a sequence of unsigned 32-bit values in little-endian format,
+denoting the sizes of the successive data blocks in the Stream Data
+field that follows this header. Each value in the sequence MUST be less than or
+equal to the data unit size, unless it spans the VDL or a hole in the case of a
+sparse file.
Extended Header (16 bytes): This field is
+optional, and its presence is indicated by the four-byte signature located at
+the start of this field. If this field is present, the server SHOULD interpret
+it as defined in section 2.2.3.4.
+The server MAY ignore this field.<20>
The method EfsRpcReadFileRaw is used by a client to obtain
+marshaled data for an encrypted object from the server.
+-
+
long EfsRpcReadFileRaw(
+ [in] PEXIMPORT_CONTEXT_HANDLE hContext,
+ [out] EFS_EXIM_PIPE* EfsOutPipe
+ );
+
hContext: A context handle returned by the EfsRpcOpenFileRaw method,
+which MUST have been called without the CREATE_FOR_IMPORT flag.
EfsOutPipe: A pipe structure. The push
+procedure of this pipe will be called with the marshaled data. The structure of
+this marshaled data is specified in section 2.2.3.
Return Values: The server MUST return 0 if it
+successfully processes the message received from the client.
If called with a context handle that has not been obtained
+by calling the EfsRpcOpenFileRaw method without the CREATE_FOR_IMPORT flag set,
+the server SHOULD throw an RPC exception.
The server MUST read data from the object and write it to
+the pipe in EFSRPC Raw Data Format until all the data in the object has been
+written. When all the data in the object has been written, the server MUST
+flush the pipe by performing a 0-byte write to the pipe, and return 0 to the
+user to indicate success.
If an error is encountered during the read, the server MUST
+flush the pipe and SHOULD throw an RPC exception. The pipe MUST be flushed by
+performing a 0-byte write to the pipe.
The EfsRpcFlushEfsCache method causes EFS to flush the logical
+cache that holds all the sensitive information required to perform EFSRPC
+operations for the calling user.
+-
+
DWORD EfsRpcFlushEfsCache(
+ [in] handle_t binding_h
+ );
+
binding_h: This is an RPC binding handle parameter,
+as specified in [C706]
+and [MS-RPCE]
+section 2.
Return Values: The server MUST return 0 if it
+successfully processes the message received from the client. The server MUST
+return a nonzero value if processing fails.
The server MUST completely discard the logical cache being
+maintained on behalf of the calling user. The logical cache is as specified in
+section 3.1.1.
The EfsRpcAddUsersToFile method is used to grant the
+possessors of the private
+keys corresponding to certain X.509 certificates the ability to
+decrypt the object.
+-
+
DWORD EfsRpcAddUsersToFile(
+ [in] handle_t binding_h,
+ [in, string] wchar_t* FileName,
+ [in] ENCRYPTION_CERTIFICATE_LIST* EncryptionCertificates
+ );
+
binding_h: This is an RPC binding handle parameter,
+as specified in [C706]
+and [MS-RPCE]
+section 2.
FileName: An EFSRPC nonzero name, as specified
+in section 2.2.1.
EncryptionCertificates: A list of
+certificates, represented by an ENCRYPTION_CERTIFICATE_LIST
+structure, which are to be given access to the object.
Return Values: The server MUST return 0 if it
+successfully processes the message received from the client. The server MUST
+return a nonzero value if processing fails.
If no object exists on the server with the specified name,
+or if the object exists and is not encrypted, the server MUST return a nonzero
+value. Otherwise, the server MUST modify the object's EFSRPC Metadata such that
+all the user certificates listed in the Users structure have the ability to
+decrypt the object.
The EfsRpcDuplicateEncryptionInfoFile method is used to
+duplicate the EFSRPC
+Metadata of one encrypted object and attach it to another encrypted object.
+This is typically done when copying objects to maintain the same set of keys and users for the copy
+as for the original.
+-
+
DWORD EfsRpcDuplicateEncryptionInfoFile(
+ [in] handle_t binding_h,
+ [in, string] wchar_t* SrcFileName,
+ [in, string] wchar_t* DestFileName,
+ [in] DWORD dwCreationDisposition,
+ [in] DWORD dwAttributes,
+ [in, unique] EFS_RPC_BLOB* RelativeSD,
+ [in] BOOL bInheritHandle
+ );
+
binding_h: This is an RPC binding handle parameter,
+as specified in [C706]
+and [MS-RPCE]
+section 2.
SrcFileName: An EFSRPC identifier, as
+specified in section 2.2.1.
DestFileName: An EFSRPC identifier, as
+specified in section 2.2.1.
dwCreationDisposition: This parameter
+specifies what action the server is advised to take if the object referred to
+by DestFileName does not already exist. It MUST be one of the following
+values.
+-
+
+
+ |
+ Value
+ |
+
+ Meaning
+ |
+
+
+ | CREATE_NEW 0x00000001 |
+ Do not overwrite the data object referred to by DestFileName if it already exists. |
+
+ | CREATE_ALWAYS 0x00000002 |
+ Overwrite the data object referred to by DestFileName if it already exists. |
+
+
dwAttributes: Desired attributes for the
+target object. Clients SHOULD set this parameter to the bitwise OR of zero or
+more of the following values. Servers SHOULD support all of these values. These
+values can be interpreted by the underlying server data store, and they do not
+affect protocol behavior.
+-
+
+
+ |
+ Value
+ |
+
+ Meaning
+ |
+
+
+ | FILE_ATTRIBUTE_HIDDEN 0x00000002 |
+ The file is hidden (not displayed in normal folder listings). |
+
+ | FILE_ATTRIBUTE_ARCHIVE 0x00000020 |
+ This attribute is used by applications to mark files for backup or removal. |
+
+ | FILE_ATTRIBUTE_TEMPORARY 0x00000100 |
+ The file is being used for temporary storage. |
+
+ | FILE_ATTRIBUTE_NOT_CONTENT_INDEXED 0x00002000 |
+ The file's contents are not to be indexed by the content indexing service. |
+
+ | FILE_ATTRIBUTE_NORMAL 0x00000080 |
+ No other attributes are to be set. |
+
+
RelativeSD: Relative security descriptor for
+the target object. The format of this is implementation-dependent.<49>
bInheritHandle: This parameter SHOULD be set
+to FALSE by the client and SHOULD be ignored by the server.
Return Values: The server MUST return 0 if it
+successfully processes the message received from the client. The server MUST
+return a nonzero value if processing fails.<50>
+-
+
If no object exists on the server with the name
+specified in the SrcFileName parameter, or if it exists and is not
+encrypted, the server MUST return a nonzero value.
+
+-
+
If an encrypted object exists with the name
+specified in the SrcFileName and dwCreationDisposition parameters
+is equal to CREATE_NEW, then:
+
+If an object exists with the name specified in the DestFileName
+parameter, the server MUST return a nonzero value.
+
+If no object exists with the name specified in the DestFileName
+parameter, the server MUST create a new object with this name and duplicate the
+EFSRPC Metadata from the SrcFileName parameter into it. If the object
+specified in SrcFileName is a container for other objects, the server
+MUST create the object as a container for objects, and it MUST encrypt any
+objects that are subsequently placed in the container after this message has
+been processed. Otherwise, the server MUST create the object as a non-container
+encrypted data object.
+If an encrypted object exists with the name
+specified in the SrcFileName and dwCreationDisposition parameters
+is not equal to CREATE_NEW, then:
+
+If an object already exists with the name specified in the DestFileName
+parameter, the server MUST check whether the object referred to by SrcFileName
+is of the same type (either simple object or container for other objects); if the
+object is not of the same type, the server MUST return a nonzero value. In
+addition, if the object referred to by DestFileName is a container for
+other objects, and it is not already encrypted, the server MUST return a
+nonzero value. Otherwise, the server SHOULD overwrite the object, clear its
+existing attributes, create a new object in its place with the attributes
+specified, and duplicate the EFSRPC Metadata from the SrcFileName
+parameter into it.
+
+If no object exists with the name specified in the DestFileName
+parameter, the server MUST create a new object with this name and duplicate the
+EFSRPC Metadata from the SrcFileName parameter into it. If the object
+specified in SrcFileName is a container for other objects, the server
+MUST create the object as a container for objects, and it MUST encrypt any
+objects that are subsequently placed in the container after this message has
+been processed. Otherwise, the server MUST create the object as a non-container
+encrypted data object.
+
In duplicating the EFSRPC Metadata from the SrcFileName
+parameter to the DestFileName parameter, the server MAY<51> change the metadata. However,
+upon successful completion, the set of users and DRAs with access to the DestFileName
+parameter MUST be the same set of users who had access to the SrcFileName
+parameter at the outset.
The method EfsRpcWriteFileRaw is used to create an encrypted
+object on the server from the marshaled data provided by the client.
+-
+
long EfsRpcWriteFileRaw(
+ [in] PEXIMPORT_CONTEXT_HANDLE hContext,
+ [in] EFS_EXIM_PIPE* EfsInPipe
+ );
+
hContext: A context handle returned by the EfsRpcOpenFileRaw method,
+which MUST have been called with the CREATE_FOR_IMPORT flag.
EfsInPipe: A pipe structure. The pull
+procedure of this pipe is expected to provide the marshaled data. The structure
+of this marshaled data is specified in section 2.2.3.
Return Values: The server MUST return 0 if it
+successfully processes the message received from the client.
If called with a context handle that has not been obtained
+by calling EfsRpcOpenFileRaw with the CREATE_FOR_IMPORT flag set, the server
+MUST abort the operation. In this case, it SHOULD throw an RPC exception.
The server MUST read data from the pipe and write it to the
+object indicated by the context handle. If an error is encountered during the
+write, the server SHOULD throw an RPC exception.
The Blob Datum encapsulates an opaque binary object. It MUST
+be formatted as below.
+
+
0
|
+
1
|
+
2
|
+
3
|
+
4
|
+
5
|
+
6
|
+
7
|
+
8
|
+
9
|
+ 1
0 |
+
1
|
+
2
|
+
3
|
+
4
|
+
5
|
+
6
|
+
7
|
+
8
|
+
9
|
+ 2
0 |
+
1
|
+
2
|
+
3
|
+
4
|
+
5
|
+
6
|
+
7
|
+
8
|
+
9
|
+ 3
0 |
+
1
|
+
+
+ | EFSX_Datum |
+
+
+ | ... |
+
+
+ | BlobType |
+ BlobFlags |
+
+
+ | Blob_Data (variable) |
+
+
+ | ... |
+
+
EFSX_Datum (8 bytes): MUST be formatted as
+specified in section 2.2.2.2.2.
+The datum Type MUST be EFSX_TYPE_BLOB (0x0001). The datum Flags MUST NOT
+include 0x0002.
BlobType (2 bytes): The type of the blob,
+which provides a hint to the format of the Blob Data. It MUST be a
+16-bit unsigned integer in little-endian format.
+-
+
+
+ |
+ Value
+ |
+
+ Meaning
+ |
+
+
+ | 0x0000 |
+ The blob has no special formatting. |
+
+ | 0x0001 |
+ The blob contains a public key formatted as a BCRYPT_PUBLIC_KEY_BLOB. |
+
+ | 0x0002 |
+ The blob contains a SHA-1 hash of a DER-encoded form of a certificate. |
+
+ | 0x0003 |
+ The blob contains the encrypted form of an Encrypted FEK structure, as defined in section 2.2.2.1.5. The contents of the key can be either the FEK or the FMK (see section 2.2.2.2.5). |
+
+ | 0x0004 |
+ The blob contains key material wrapped with an AES-256 key wrapping key, as defined by [RFC3394]. |
+
+ | 0x0005 |
+ The blob contains key material encrypted by a DPAPI-NG provider on the endpoint. This BlobType MUST only be used when EFS_VERSION is 5.<17> |
+
+
BlobFlags (2 bytes): Reserved, MUST be 0x0000.
Blob_Data (variable): Contains opaque,
+variable-length data. The Blob Data MUST be entirely contained within
+the Blob Datum.
The EFS_ENCRYPTION_STATUS_INFO structure is used to
+represent the predicted outcome if an attempt were made to convert an
+unencrypted object to an encrypted state.
+-
+
typedef struct {
+ BOOL bHasCurrentKey;
+ DWORD dwEncryptionError;
+ } EFS_ENCRYPTION_STATUS_INFO;
+
bHasCurrentKey: A Boolean value
+signifying whether an appropriate key was found that could be
+used for encryption.
dwEncryptionError: The error code
+returned if encryption were attempted. If the operation were to succeed, this
+value MUST be zero. Otherwise, it MUST be set to a nonzero value.
The EfsRpcCloseRaw method is called to release any resources
+allocated by the EfsRpcOpenFileRaw
+method, or by subsequent calls to the EfsRpcReadFileRaw or EfsRpcWriteFileRaw
+methods.
+-
+
void EfsRpcCloseRaw(
+ [in, out] PEXIMPORT_CONTEXT_HANDLE* hContext
+ );
+
Return Values: This method has no return
+values.
The EfsRpcOpenFileRaw method is used to open an encrypted
+object on the server for backup or restore. It allocates resources that MUST be
+released by calling the EfsRpcCloseRaw
+method.<42>
+-
+
long EfsRpcOpenFileRaw(
+ [in] handle_t binding_h,
+ [out] PEXIMPORT_CONTEXT_HANDLE* hContext,
+ [in, string] wchar_t* FileName,
+ [in] long Flags
+ );
+
binding_h: An explicit binding handle created by
+the client. This is an RPC binding handle parameter, as specified in [C706] and [MS-RPCE]
+section 2.
hContext: An implementation-specific context
+handle that is used in subsequent calls by the client to the EfsRpcReadFileRaw method, EfsRpcWriteFileRaw method,
+or EfsRpcCloseRaw method.
FileName: An EFSRPC identifier, as specified
+in section 2.2.1.
Flags: This MUST be set to some combination of
+the following values. All servers and clients MUST support the CREATE_FOR_IMPORT
+flag. Servers that implement a hierarchical encrypted store, such as the NTFS
+file system, SHOULD also support the CREATE_FOR_DIR flag. Servers SHOULD
+support the OVERWRITE_HIDDEN flag, and MAY interpret it in
+implementation-specific ways. A client MUST ensure that all the flags it does
+not support are set to zero. A server MUST ignore all flags it does not
+support. Flag values are specified in the following table.
+-
+
+
+ |
+ Value
+ |
+
+ Meaning
+ |
+
+
+ | CREATE_FOR_IMPORT 0x00000001 |
+ Open the object for writing (that is, restore). If this flag is not set, open the object for reading (that is, backup). |
+
+ | CREATE_FOR_DIR 0x00000002 |
+ This flag is only intended for use in conjunction with the CREATE_FOR_IMPORT flag. It indicates that the object being restored is a container for other objects.<43> |
+
+ | OVERWRITE_HIDDEN 0x00000004 |
+ This flag is only intended for use in conjunction with the CREATE_FOR_IMPORT flag. This flag indicates a request from the client for the server to overwrite an existing object even if the existing object is "hidden". The meaning of "hidden" is specific to the implementation of the data store, and this meaning does not affect protocol behavior. |
+
+ | EFS_DROP_ALTERNATE_STREAMS 0x00000010 |
+ This flag indicates that content from any alternate data streams, if present and implemented by the storage system, will be ignored. |
+
+
Return Values: The server MUST return 0 if it
+successfully processes the message received from the client. The server MUST
+return a nonzero value if processing fails.
First, the server SHOULD perform any additional access
+checks prescribed by the implementation. If any of these checks fail, it MUST
+return a nonzero value.
EFSRPC servers SHOULD return an error unless at least one of
+the following conditions is true:
+The calling user has a private key that grants the
+user authorized access to the file.
+
+The CREATE_FOR_IMPORT flag is set, and the user has
+restore rights on the server.
+
+The CREATE_FOR_IMPORT flag is not set, and the user has
+backup rights on the server.
+
If the CREATE_FOR_IMPORT flag is set, the server MUST
+attempt to create an object with the given name and prepare it for writing data
+received in future EfsRpcWriteFileRaw calls. The server MUST return a nonzero
+value if this fails.
If the CREATE_FOR_IMPORT flag is not set, the server
+MUST attempt to locate the object requested and prepare it for reading data to
+be sent through future EfsRpcReadFileRaw calls. The server MUST return a
+nonzero value if it fails.
If the server supports the CREATE_FOR_DIR flag, and
+this flag is set:
+If the CREATE_FOR_IMPORT flag is not set:
+ If
+the data object referred to by FileName exists on the server and is not
+a container for other objects, the server SHOULD return a nonzero value.
+ Otherwise,
+the server SHOULD ignore the CREATE_FOR_DIR flag.
+
+If the CREATE_FOR_IMPORT flag is set, the server MUST
+attempt to create a container with the given name and prepare it for writing
+data received in future EfsRpcWriteFileRaw calls. The server MUST return a
+nonzero value if this fails.
+
If the server supports the OVERWRITE_HIDDEN flag, and
+this flag is set:
+If the CREATE_FOR_IMPORT flag is not set, the server
+SHOULD ignore this flag.
+
+If the CREATE_FOR_IMPORT flag is set, the server SHOULD
+overwrite an existing object even if the object is "hidden". The
+meaning of "hidden" is specific to the implementation of the data
+store, and this meaning does not affect protocol behavior.
+
The server MUST ignore any flags that it does not support.
On success, the server MUST create an appropriate context
+handle and return it to the client.
The EfsRpcQueryRecoveryAgents method is used to query the EFSRPC Metadata of an
+encrypted object for the X.509
+certificates of the data
+recovery agents whose private keys
+can be used to decrypt the object.
+-
+
DWORD EfsRpcQueryRecoveryAgents(
+ [in] handle_t binding_h,
+ [in, string] wchar_t* FileName,
+ [out] ENCRYPTION_CERTIFICATE_HASH_LIST** RecoveryAgents
+ );
+
binding_h: This is an RPC binding handle parameter,
+as specified in [C706]
+and [MS-RPCE]
+section 2.
FileName: An EFSRPC identifier as specified in
+section 2.2.1.
RecoveryAgents: A list of certificate hashes,
+represented by an ENCRYPTION_CERTIFICATE_HASH_LIST
+structure.
Return Values: The server MUST return 0 if it
+successfully processes the message received from the client. The server MUST
+return a nonzero value if processing fails.
+-
+
If no object exists on the server with the specified
+name, or if the object exists and is not encrypted, the server MUST return a
+nonzero value. Otherwise, the server MUST read the object's EFSRPC Metadata and
+return a list of the hashes of all the DRA certificates that have
+access to the object in the RecoveryAgents parameter. The server MUST
+NOT include any certificates that were not added by virtue of being defined as
+DRAs in administrative policy. If no DRAs are defined on the object, the call
+MUST return success and this list MUST be empty.
+
On receiving the EfsRpcFileKeyInfoEx method call, an EFSRPC
+server SHOULD ignore the input parameters and return a nonzero value. The
+server MAY act on this method in an implementation-specific manner.<52>
+-
+
DWORD EfsRpcFileKeyInfoEx(
+ [in] handle_t binding_h,
+ [in] DWORD dwFileKeyInfoFlags,
+ [in, unique] EFS_RPC_BLOB* Reserved,
+ [in, string] wchar_t* FileName,
+ [in] DWORD InfoClass,
+ [out] EFS_RPC_BLOB** KeyInfo
+ );
+
binding_h: This is an RPC binding handle parameter,
+as specified in [C706]
+and [MS-RPCE]
+section 2.
dwFileKeyInfoFlags: This parameter is
+reserved. It MUST be set to zero by the client and ignored by the server.
Reserved: This parameter is reserved. It MUST
+be set to NULL by the client and ignored by the server.
FileName: An EFSRPC identifier, as specified
+in section 2.2.1.
InfoClass: One of the values specified for the
+InfoClass parameter of the EfsRpcFileKeyInfo method.
KeyInfo: The server SHOULD ignore this
+parameter.<53>
Return Values: The server SHOULD return a
+nonzero value.<54>
The EfsRpcAddUsersToFileEx method is used to grant the
+possessors of the private
+keys corresponding to certain X.509 certificates the ability to
+decrypt the object.
+-
+
DWORD EfsRpcAddUsersToFileEx(
+ [in] handle_t binding_h,
+ [in] DWORD dwFlags,
+ [in, unique] EFS_RPC_BLOB* Reserved,
+ [in, string] wchar_t* FileName,
+ [in] ENCRYPTION_CERTIFICATE_LIST* EncryptionCertificates
+ );
+
binding_h: This is an RPC binding handle parameter,
+as specified in [C706]
+and [MS-RPCE]
+section 2.
dwFlags: This MUST be set to a bitwise OR of 0
+or more of the following flags. The descriptions of the flags are specified in
+the following table. If the EFSRPC_ADDUSERFLAG_REPLACE_DDF flag is used, then
+the EncryptionCertificates parameter MUST contain exactly one
+certificate.
+-
+
+
+ |
+ Name
+ |
+
+ Value
+ |
+
+
+ | EFSRPC_ADDUSERFLAG_ADD_POLICY_KEYTYPE |
+ 0x00000002 |
+
+ | EFSRPC_ADDUSERFLAG_REPLACE_DDF |
+ 0x00000004 |
+
+
Reserved: This parameter is not used. It MUST
+be set to NULL by the client and ignored by the server.
FileName: An EFSRPC identifier, as specified
+in section 2.2.1.
EncryptionCertificates: A list of
+certificates, represented by an ENCRYPTION_CERTIFICATE_LIST
+structure, which are to be given access to the object.
Return Values: The server MUST return 0 if it
+successfully processes the message received from the client. The server MUST
+return a nonzero value if processing fails.
+-
+
If no object exists on the server with the specified
+name, or if it exists and is not encrypted, the server MUST return a nonzero
+value.
+
+-
+
If the EFSRPC_ADDUSERFLAG_REPLACE_DDF flag is set in
+the dwFlags parameter, and the EncryptionCertificates parameter
+contains more than one certificate, the server MUST return a nonzero value.
+
+-
+
If the EFSRPC_ADDUSERFLAG_REPLACE_DDF flag is set in
+the dwFlags parameter, and the calling user does not have the ability to
+decrypt the object, the server MUST return a nonzero value.
+
+-
+
If the EFSRPC_ADDUSERFLAG_REPLACE_DDF flag is set in
+the dwFlags parameter, and the user certificate in the EncryptionCertificates
+parameter already has access to the object, then the server MUST return a zero
+value.
+
If the EFSRPC_ADDUSERFLAG_ADD_POLICY_KEYTYPE flag is
+specified in the dwFlags parameter, then for each certificate specified
+in the EncryptionCertificates parameter, the server MUST check whether
+the private key for the
+certificate is stored on a smart card. If the key is stored, the server MUST
+return a nonzero value; otherwise, the server MUST ignore this flag.
If the EFSRPC_ADDUSERFLAG_REPLACE_DDF flag is set in the dwFlags
+parameter, and the calling user has the ability to decrypt the object, then the
+certificate in the EncryptionCertificates parameter is to be given
+access to the object, replacing one of the calling user's user certificates
+through which he currently has access.
The Public Key Information structure MUST be formatted as
+follows.
+
+
0
|
+
1
|
+
2
|
+
3
|
+
4
|
+
5
|
+
6
|
+
7
|
+
8
|
+
9
|
+ 1
0 |
+
1
|
+
2
|
+
3
|
+
4
|
+
5
|
+
6
|
+
7
|
+
8
|
+
9
|
+ 2
0 |
+
1
|
+
2
|
+
3
|
+
4
|
+
5
|
+
6
|
+
7
|
+
8
|
+
9
|
+ 3
0 |
+
1
|
+
+
+ | Length |
+
+
+ | Offset to Owner Hint |
+
+
+ | 0x03 |
+ 0x00 |
+ 0x00 |
+ 0x00 |
+
+
+ | Length of Certificate Data |
+
+
+ | Offset to Certificate Data |
+
+
+ | Reserved |
+
+
+ | ... |
+
+
+ | Data Fields (variable) |
+
+
+ | ... |
+
+
Length (4 bytes): This MUST be set to the
+length, in bytes, of this structure. It MUST be a 32-bit unsigned integer in
+little-endian format.
Offset to Owner Hint (4 bytes): If the Owner
+Hint field is present, this field MUST be set to the offset of the Owner
+Hint from the beginning of this structure, measured in bytes. If this field
+is zero, then the Owner Hint field MUST NOT be present. This field MUST
+be a 32-bit unsigned integer in little-endian format.
Length of Certificate Data (4 bytes): The
+size, in bytes, of the Certificate Data field. It MUST be a 32-bit
+unsigned integer in little-endian format.
Offset to Certificate Data (4 bytes): The
+offset, in bytes, of the Certificate Data field from the start of this
+structure. It MUST be a 32-bit unsigned integer in little-endian format.
Reserved (8 bytes): MUST be set to zero and
+ignored upon receipt.
Data Fields (variable): This field MUST
+contain the following items, in any order, and at the locations indicated by
+the respective Offset fields above. These items MUST be completely
+contained inside this field and MUST NOT overlap each other. There MUST NOT be
+any unused areas within this field that span more than eight contiguous bytes.
+-
+
+
+
0
|
+
1
|
+
2
|
+
3
|
+
4
|
+
5
|
+
6
|
+
7
|
+
8
|
+
9
|
+ 1
0 |
+
1
|
+
2
|
+
3
|
+
4
|
+
5
|
+
6
|
+
7
|
+
8
|
+
9
|
+ 2
0 |
+
1
|
+
2
|
+
3
|
+
4
|
+
5
|
+
6
|
+
7
|
+
8
|
+
9
|
+ 3
0 |
+
1
|
+
+
+ | Owner Hint (variable) |
+
+
+ | ... |
+
+
+ | Certificate Data (variable) |
+
+
+ | ... |
+
+
+
+-
+
Owner Hint (variable): A
+security identifier (SID)
+in RPC marshaling format that is intended to be used as a hint regarding the
+identity of the key
+owner. This item MUST be present only if the Offset to Owner Hint field
+is nonzero. The structure of an RPC SID is specified in [MS-DTYP]
+section 2.4.2.3.
+
+-
+
Certificate Data
+(variable): This field MUST contain information about the X.509 certificate associated with
+the public key that is
+used to encrypt the FEK
+data in this key list entry. It MUST be formatted as specified in section 2.2.2.1.4.
+
The EFSRPC raw data format is used by the EFSRPC raw
+methods. The output of the EfsRpcReadFileRaw
+method MUST conform to this format. The input to the EfsRpcWriteFileRaw method
+MUST conform to the EFSRPC Raw Data Format. The details of this format are
+implementation dependent. An EFSRPC client SHOULD NOT parse this format and
+SHOULD NOT rely on it having any particular structure. An EFSRPC server MUST
+validate input data passed to it by the EfsRpcWriteFileRaw method, and SHOULD
+abort the EfsRpcWriteFileRaw operation with an RPC exception if this data is in
+an unsupported format.
The EFSRPC Raw Data Format SHOULD be formatted as follows.
+
+
0
|
+
1
|
+
2
|
+
3
|
+
4
|
+
5
|
+
6
|
+
7
|
+
8
|
+
9
|
+ 1
0 |
+
1
|
+
2
|
+
3
|
+
4
|
+
5
|
+
6
|
+
7
|
+
8
|
+
9
|
+ 2
0 |
+
1
|
+
2
|
+
3
|
+
4
|
+
5
|
+
6
|
+
7
|
+
8
|
+
9
|
+ 3
0 |
+
1
|
+
+
+ | 0x00 |
+ 0x01 |
+ 0x00 |
+ 0x00 |
+
+
+ | 0x52 |
+ 0x00 |
+ 0x4f |
+ 0x00 |
+
+
+ | 0x42 |
+ 0x00 |
+ 0x53 |
+ 0x00 |
+
+
+ | Reserved |
+
+
+ | ... |
+
+
+ | EFSRPC Metadata Stream (variable) |
+
+
+ | ... |
+
+
+ | Additional Stream 1 (variable) |
+
+
+ | ... |
+
+
+ | Additional Stream n (variable) |
+
+
+ | ... |
+
+
Reserved (8 bytes): MUST be set to zero and
+ignored.
EFSRPC Metadata Stream (variable): This field
+MUST be formatted as specified in section 2.2.3.1. This field MUST
+contain the EFSRPC Metadata
+for the file, along with
+a header. The structure of the EFSRPC Metadata is specified in section 2.2.2.
Additional Stream 1 ... n: These MUST
+correspond to marshaled versions of all the streams (except for EFSRPC Metadata) in the
+given file. They are optional and might not exist (for example, for folders with no alternate
+streams). For more information on NTFS file streams, see [MSFT-NTFS]. These
+fields MUST be formatted as specified in section 2.2.3.1.
The EFS_CERTIFICATE_BLOB type is used to represent the
+encoded contents of an X.509
+certificate.
+-
+
typedef struct _CERTIFICATE_BLOB {
+ DWORD dwCertEncodingType;
+ [range(0,32768)] DWORD cbData;
+ [size_is(cbData)] unsigned char* bData;
+ } EFS_CERTIFICATE_BLOB;
+
dwCertEncodingType: The certificate
+encoding type. This MUST be set to one of the following values. If set to any
+other value, the certificate is considered invalid and behavior is undefined.
+-
+
+
+ |
+ Value
+ |
+
+ Meaning
+ |
+
+
+ | 0x00000001 |
+ Certificate uses X.509 ASN.1 encoding. |
+
+ | 0x00000002 |
+ Certificate uses X.509 NDR encoding. |
+
+
cbData: The number of bytes in the
+bData buffer.
bData: An encoded X.509 certificate.
+Its format is specified by the dwCertEncodingType member. For more
+information on ASN encoding, see [X690]. NDR encoding
+is specified in [C706].<21>
Each individual Key List Entry MUST be formatted as follows.
+
+
+
0
|
+
1
|
+
2
|
+
3
|
+
4
|
+
5
|
+
6
|
+
7
|
+
8
|
+
9
|
+ 1
0 |
+
1
|
+
2
|
+
3
|
+
4
|
+
5
|
+
6
|
+
7
|
+
8
|
+
9
|
+ 2
0 |
+
1
|
+
2
|
+
3
|
+
4
|
+
5
|
+
6
|
+
7
|
+
8
|
+
9
|
+ 3
0 |
+
1
|
+
+
+ | Length |
+
+
+ | Offset to Public Key Information |
+
+
+ | Encrypted FEK Length |
+
+
+ | Offset to Encrypted FEK |
+
+
+ | Flags |
+
+
+ | Data Fields (variable) |
+
+
+ | ... |
+
+
Length (4 bytes): MUST be equal to the length
+of this key list entry in bytes. It MUST be a 32-bit unsigned integer in
+little-endian format.
Offset to Public Key Information (4 bytes): MUST
+contain the offset to the Public Key Information field in bytes from the
+start of this entry. It MUST be a 32-bit unsigned integer in little-endian
+format. The Public Key Information field MUST be completely contained
+inside the Data Fields.
Encrypted FEK Length (4 bytes): MUST be set to
+the length of the data in the Encrypted FEK field, in bytes. It MUST be
+a 32-bit unsigned integer in little-endian format.
Offset to Encrypted FEK (4 bytes): MUST
+contain the offset to the Encrypted FEK field, in bytes from the start
+of this entry. It MUST be a 32-bit unsigned integer in little-endian format.
+The Encrypted FEK MUST be completely contained inside the Data
+fields.
Flags (4 bytes): This field MUST indicate the
+algorithm used to encrypt the FEK
+in this key list entry. It MUST be a 32-bit unsigned integer in little-endian
+format. EFSRPC servers SHOULD support all the values listed below, and MUST
+ignore any unsupported values.
+-
+
+
+ |
+ Value
+ |
+
+ Meaning
+ |
+
+
+ | 0x00000000 |
+ The Encrypted FEK field is encrypted using RSA, with a public key belonging to a user or DRA. |
+
+ | 0x00000001 |
+ The Encrypted FEK field is encrypted using AES-256, with a key that is obtained by signing the non-terminated Unicode string "MICROSOFTE" (20 bytes long) with the user's RSA and computing the SHA-256 hash of the result. This value is used when a user's private key is stored on a smart card to improve performance by minimizing the number of smart card accesses.<10> |
+
+
Data Fields (variable): This field MUST
+contain the following items, in any order, at the locations indicated by the
+respective Offset fields previously listed. These items MUST be
+completely contained inside this field and MUST NOT overlap each other. There
+MUST NOT be unused areas within this field spanning more than 8 contiguous
+bytes.
+-
+
+
+
0
|
+
1
|
+
2
|
+
3
|
+
4
|
+
5
|
+
6
|
+
7
|
+
8
|
+
9
|
+ 1
0 |
+
1
|
+
2
|
+
3
|
+
4
|
+
5
|
+
6
|
+
7
|
+
8
|
+
9
|
+ 2
0 |
+
1
|
+
2
|
+
3
|
+
4
|
+
5
|
+
6
|
+
7
|
+
8
|
+
9
|
+ 3
0 |
+
1
|
+
+
+ | Public Key Information (variable) |
+
+
+ | ... |
+
+
+ | Encrypted FEK (variable) |
+
+
+ | ... |
+
+
+
+-
+
Public Key Information
+(variable): This field MUST contain information about the X.509 certificate that contains
+the RSA public key, which is used to encrypt the Encrypted FEK field. It
+MUST be formatted as specified in section 2.2.2.1.3.
+
+-
+
Encrypted FEK (variable):
+This field MUST contain information about the FEK, encrypted as indicated
+by the contents of the Flags field. It MUST be formatted as specified in
+section 2.2.2.1.5.
+
The Fek Info datum encapsulates the algorithm ID (ALG_ID) used for the FEK,
+the encrypted FEK, and the File IV. The FEK and File IV are both protected
+using advanced encryption
+standard (AES) keywrap, with the FMK as the wrapping key.
+
+
0
|
+
1
|
+
2
|
+
3
|
+
4
|
+
5
|
+
6
|
+
7
|
+
8
|
+
9
|
+ 1
0 |
+
1
|
+
2
|
+
3
|
+
4
|
+
5
|
+
6
|
+
7
|
+
8
|
+
9
|
+ 2
0 |
+
1
|
+
2
|
+
3
|
+
4
|
+
5
|
+
6
|
+
7
|
+
8
|
+
9
|
+ 3
0 |
+
1
|
+
+
+ | EFSX_Datum |
+
+
+ | ... |
+
+
+ | AlgorithmID |
+
+
+ | Data_Fields (variable) |
+
+
+ | ... |
+
+
EFSX_Datum (8 bytes): MUST be formatted as
+specified in section 2.2.2.2.2.
+The datum Type MUST be EFSX_TYPE_FEK_INFO (0x0006). The datum Flags
+SHOULD include 0x0002, indicating a complex datum.
AlgorithmID (4 bytes): The symmetric
+cryptographic algorithm associated with this key. It MUST be a 32-bit unsigned
+integer in little-endian format. Possible values are specified in section
+2.2.13.
Data_Fields (variable): This field contains
+any number of nested EFSX_Datum structures. The nested datum structures MUST
+NOT overlap, and MUST be entirely contained within the Fek Info datum. This
+field MUST contain at least two datum structures of type EFSX_TYPE_BLOB
+(0x0001). These blobs MUST have Role fields set to 0x000a (for the
+encrypted FEK) and 0x000b (for the encrypted File IV), respectively. The BlobType
+for these blobs MUST be 0x0004, indicating that the blob data contains a key
+wrapped with an AES 256 key encryption key, as defined in [RFC3394].