Using Windows and bitlocker

Using Windows and bitlocker

[Mark Foley]

I have been asked to encrypt files on the office shared drive. After researching
I was pointed to LUKS and cryptsetup.

The shared drive is a Samba shared directory hosted on Linux. Windows users map
this partition on their Windows 11 workstations.

I've downloaded and installed cryptsetup 2.7.5. Linux forum feedback has
advised me that Windows uses BitLocker for security/encryption and that
cryptsetup supports this. The README.md of the downloaded cryptsetup tarball
says at the very beginning:

These formats are supported:
  * **plain** volumes,
  * **LUKS** volumes,
  * **loop-AES**,
  * **TrueCrypt** (including **VeraCrypt** extension),
--> **BitLocker**, and
  * **FileVault2**.

A Google search on this topic gives:

  "BitLocker is a disk encryption feature in Windows, and while you can access
  BitLocker volumes in Linux using cryptsetup with Bitlocker support enabled, you
  cannot create a LUKS volume that is directly compatible with BitLocker. 

  Instead, you would need to choose one encryption method for the partition
  (either BitLocker or LUKS) and then utilize tools like cryptsetup with Bitlocker
  support or dislocker to access the encrypted drive from the other operating system."

I'll confess I don't really understand the above (cannot create a LUKS volume
that is directly compatible with BitLocker? The "Instead ..." bit does not
enlighten me.)

I've read the FAQ https://gitlab.com/cryptsetup/cryptsetup/-/wikis/FrequentlyAskedQuestions,
and the manpage, but there is no mention of using BitLocker and I've found no
examples on how to do this. 

I have a couple of empty partitions ready to test with, and I believe I can set
up an encrypted partition using 'cryptsetup luksFormat' and 'cryptsetup
luksOpen' per numerous examples I've seen.

Questions:

Is cryptsetup the right choice for Windows/Samba access of entrypted drives/
partitions on Linux?

If so, do I need to use BitLocker from Windows?

If so, How do I set that up with cryptsetup?

Thanks --Mark

Re: Using Windows and bitlocker

[Michael Kjörling]

On 19 Jun 2025 11:57 -0400, from mfoley@novatec-inc.com (Mark Foley):
> [...] I've downloaded and installed cryptsetup 2.7.5. [...]

Most Linux distributions include cryptsetup in their repositories; you
should not need to download and install it manually through
out-of-band means. Using the distribution's packaged version is
generally better unless you are working on the cryptsetup code; you
get updates through the distribution's normal update process, and you
don't risk unknowingly introducing incompatibilities between for
example the kernel, libcryptsetup, and cryptsetup.


> I have a couple of empty partitions ready to test with, and I believe I can set
> up an encrypted partition using 'cryptsetup luksFormat' and 'cryptsetup
> luksOpen' per numerous examples I've seen.
> 
> Questions:
> 
> Is cryptsetup the right choice for Windows/Samba access of entrypted drives/
> partitions on Linux?
> 
> If so, do I need to use BitLocker from Windows?
> 
> If so, How do I set that up with cryptsetup?

I'm afraid you are confusing two somewhat different, related concepts,
and that this is a significant source of your confusion.

Microsoft's Bitlocker, LUKS on Linux, VeraCrypt, and others are
examples of _full-disk encryption_ (FDE) solutions.

Full-disk encryption is mainly about protecting _data at rest_. The
typical example is if someone steals a laptop, or an external storage
device used to hold backups. (It's also useful in other situations, of
course.)

Once the system is booted and the volume is unlocked, full-disk
encryption is generally designed to allow access to the storage device
as if it was not encrypted in the first place. With LUKS, this is done
through Linux device mapper dm-crypt mappings, controlled using the
cryptsetup tool and its underlying libcryptsetup library. (Bitlocker
is a bit of a hybrid as it integrates with NTFS file encryption and
access control on supported Windows systems as well as typically use
the system TPM for transparent volume decryption.)

Using full-disk encryption _provides the capability_ to ensure that if
someone for example steals the file server, the thief won't be able to
access the files stored on it because they cannot open the volume.
Without the key material, it looks like random data; there is no way
to know whether that data represents a design for a new fighter jet or
a photo of a kitten.

What you are more likely looking for here is _access control_.

Access control works on a directory/folder or file level, and is about
which authenticated users (if any) can access which directories or
files. Windows ACLs and Unix-style file permissions are examples of
how access control can be manifested.

Access control in an environment like you describe can be configured
for example by restricting certain shares in Samba to certain users or
groups, depending on who should have access to what. (It's been ages
since I did anything of the sort, and this mailing list is the wrong
place to discuss how to do that.) The Samba server software will then
(assuming it is implemented and configured correctly) enforce those
restrictions on any accesses through it. However, Samba needs to be
able to read (and write, if anyone has write access) everything for
this to work.

Correspondingly, Samba essentially doesn't concern itself with the
underlying storage stack, including LUKS; it operates on directories,
which may be a part of one, all of one, or contain a combination of
several file systems.

So, _ignoring_ the tooling: _what's your goal?_ At-rest protection,
access control during use, or both?

-- 
Michael Kjörling
🔗 https://michael.kjorling.se

Re: Using Windows and bitlocker

[Mark Foley]

On Thu, 19 Jun 2025 21:45:30 Michael Kjörling <152cc69a347e@ewoof.net>wrote:
>
> On 19 Jun 2025 11:57 -0400, from mfoley@novatec-inc.com (Mark Foley):
> > [...] I've downloaded and installed cryptsetup 2.7.5. [...]
>
> Most Linux distributions include cryptsetup in their repositories; you
> should not need to download and install it manually through
> out-of-band means. Using the distribution's packaged version is
> generally better unless you are working on the cryptsetup code; you
> get updates through the distribution's normal update process, and you
> don't risk unknowingly introducing incompatibilities between for
> example the kernel, libcryptsetup, and cryptsetup.

Michael, thanks for your prompt response. My distro (Slackware) does not ship
with cryptsetup, but I built/installed from
https://gitlab.com/cryptsetup/cryptsetup. The build, make and 'make test' all
completed without error. Slackware is pretty generic in terms of kernel and libs.

> > I have a couple of empty partitions ready to test with, and I believe I can set
> > up an encrypted partition using 'cryptsetup luksFormat' and 'cryptsetup
> > luksOpen' per numerous examples I've seen.
> > 
> > Questions:
> > 
> > Is cryptsetup the right choice for Windows/Samba access of entrypted drives/
> > partitions on Linux?
> > 
> > If so, do I need to use BitLocker from Windows?
> > 
> > If so, How do I set that up with cryptsetup?
>
> I'm afraid you are confusing two somewhat different, related concepts,
> and that this is a significant source of your confusion.
>
> Microsoft's Bitlocker, LUKS on Linux, VeraCrypt, and others are
> examples of _full-disk encryption_ (FDE) solutions.
>
> Full-disk encryption is mainly about protecting _data at rest_. The
> typical example is if someone steals a laptop, or an external storage
> device used to hold backups. (It's also useful in other situations, of
> course.)

Yes, that "at rest" thing was something I was suspecting. There is little chance
of someone stealing this server as it is in a secure location behind two locked
entries with keycard, motion detection alarms, etc.

The reason I am investigating this is because our insurer recommended that we
encrypt the sensitive data on this Samba share.

> Once the system is booted and the volume is unlocked, full-disk
> encryption is generally designed to allow access to the storage device
> as if it was not encrypted in the first place. 

One thought that occured to me ...  perhaps a Windows user, for example, might
have to enter the passphrase when mapping this encrypted partition.  But,
regardless of whether bitLocker, LUKS or some other disk encryption mechanism is
used, if a Windows user, or a Linux user on the Samba host, can read/write these
"encrypted" files, I would assume than any malicious actor that would gain
access to either the Windows workstation or the Linux host, would also have
read/write access to these files, unencrypted. Yes?

In which case encrypting would be useless. I think that might go for
exfiltration as well if, for example, a malicious actor acquired scp
credentials. In such a case scp'ing the "encrypted" files would exfiltrate them
unencrypted since, presumably, the credentialled user would be able to
read/write these files in an unencrypted matter. 

Is all the correct?

[snip]

> What you are more likely looking for here is _access control_.

Yes, I already use access controls on files and directories on this Samba share.
But, that means authorized users can access these files. If a malicious actor
gains access to a legitimate user's workstation, he/she can access these files
without problem, right?

If everything I've theorized above is true, it doesn't sound like LUKS, or other
disk/partition encryption is going to be useful.

[snip]

> So, _ignoring_ the tooling: _what's your goal?_ At-rest protection,
> access control during use, or both?
>
> -- 
> Michael Kjörling
> 🔗 https://michael.kjorling.se

As I mentioned, the goal was to satisfy the cyber-insurance provider's request
that we encrypt high-value data.

Currently, only authorized users with Windows domain credential can access the
Samba share, and there are certain folders/files further restricted with ACLs.

The root user has access for the purposes of backup.  The only Linux user on
this system is me, and I am the only one who can log in from the outside world
(restricted in /etc/ssh/sshd_config).  There is also a batch-only user which
does scheduled (cron) file transmission via sftp.  There are countermeasure in
place to detect and block anyone trying to break into the Linux host within 10
seconds of the attempt (and I get notified) -- although logfiles show they've
never actually tried my user ID. 

So, what's the verdict? LUKS is the wrong tool for the job?

Thanks --Mark

Re: Using Windows and bitlocker

[Michael Kjörling]

On 19 Jun 2025 18:55 -0400, from mfoley@novatec-inc.com (Mark Foley):
> One thought that occured to me ...  perhaps a Windows user, for example, might
> have to enter the passphrase when mapping this encrypted partition.

I don't see any meaningful way in which that would work, at least in
the context of LUKS. Samba would be looking for the contents of the
mounted file system, for which the LUKS container first needs to be
opened; if the file system is not mounted, for example because the
LUKS container has not yet been opened, to Samba the backing location
for the share is just an empty directory and it would appear as such
to remote clients accessing it that way.

> But,
> regardless of whether bitLocker, LUKS or some other disk encryption mechanism is
> used, if a Windows user, or a Linux user on the Samba host, can read/write these
> "encrypted" files, I would assume than any malicious actor that would gain
> access to either the Windows workstation or the Linux host, would also have
> read/write access to these files, unencrypted. Yes?

Correct. LUKS doesn't change who has access and how after the
container is opened. It _does_ protect typically the underlying file
system block device from _meaningful_ access in situations where the
container has not been opened.

(An adversary can of course read out the ciphertext as well as the
LUKS header if the latter is not detached, but having access to those
will generally not allow inferring anything about the actual
_meaningful_ data stored there except _possibly_ roughly how much is
stored and where within the container; assuming in the case of the
LUKS header being available to an adversary that the container uses a
strong passphrase.)


> In which case encrypting would be useless. I think that might go for
> exfiltration as well if, for example, a malicious actor acquired scp
> credentials. In such a case scp'ing the "encrypted" files would exfiltrate them
> unencrypted since, presumably, the credentialled user would be able to
> read/write these files in an unencrypted matter. 
> 
> Is all the correct?

The files would be encrypted _on disk_ (at rest), but when read
through normal means the dm-crypt mapping (set up through cryptsetup
and configured through LUKS) what the file I/O syscalls would provide
is the plaintext data. That in turn is what Samba would expose to
remote clients, being what Samba sees.

LUKS does not offer the kind of granular access control I get the
distinct feeling that you are looking for.


> Yes, I already use access controls on files and directories on this Samba share.
> But, that means authorized users can access these files. If a malicious actor
> gains access to a legitimate user's workstation, he/she can access these files
> without problem, right?

Yes, and LUKS (or any other kind of full-disk encryption itself) would
not change that. From the point of view of the remote server, the
computer would be accessing files using valid credentials.


> If everything I've theorized above is true, it doesn't sound like LUKS, or other
> disk/partition encryption is going to be useful.
> 
> [snip]
> 
> As I mentioned, the goal was to satisfy the cyber-insurance provider's request
> that we encrypt high-value data.
> 
> Currently, only authorized users with Windows domain credential can access the
> Samba share, and there are certain folders/files further restricted with ACLs.

The latter is probably about the best you can do for access control.
You might consider reversing the ACL setup, only allowing access on a
need-to-have basis rather than blocking access to particularly
sensitive data, but that doesn't change the overall argument in this
thread.

LUKS can be used to prevent wholesale access to the data for someone
who gains access to the underlying block device. That can include, for
example, a decommissioned partly-faulty drive which someone might be
able to get their hands on later and send off to a data recovery firm.


> So, what's the verdict? LUKS is the wrong tool for the job?

For access control purposes in a multi-user remote environment, yes, I
would say LUKS is likely not the best tool. Samba's ACLs and
restricting access to the file system the files are stored within on
the server to the user which Samba runs as is probably a better
alternative in the situation you describe.

-- 
Michael Kjörling
🔗 https://michael.kjorling.se

Re: Using Windows and bitlocker

[Milan Broz]

On 6/20/25 12:55 AM, Mark Foley wrote:
> On Thu, 19 Jun 2025 21:45:30 Michael Kjörling <152cc69a347e@ewoof.net>wrote:
>>
>> On 19 Jun 2025 11:57 -0400, from mfoley@novatec-inc.com (Mark Foley):
>>> [...] I've downloaded and installed cryptsetup 2.7.5. [...]
>>
>> Most Linux distributions include cryptsetup in their repositories; you
>> should not need to download and install it manually through
>> out-of-band means. Using the distribution's packaged version is
>> generally better unless you are working on the cryptsetup code; you
>> get updates through the distribution's normal update process, and you
>> don't risk unknowingly introducing incompatibilities between for
>> example the kernel, libcryptsetup, and cryptsetup.
> 
> Michael, thanks for your prompt response. My distro (Slackware) does not ship
> with cryptsetup

AFAIK Slackware packages cryptsetup, at least in recent versions.
While it is one of the oldest distros I know, it is not so generic :)

Milan

Re: Using Windows and bitlocker

[Mark Foley]

On Fri Jun 20 09:09:43 2025 Milan Broz <gmazyland@gmail.com> wrote:
>
> On 6/20/25 12:55 AM, Mark Foley wrote:
> > On Thu, 19 Jun 2025 21:45:30 Michael Kjörling <152cc69a347e@ewoof.net>wrote:
> >>
> >> On 19 Jun 2025 11:57 -0400, from mfoley@novatec-inc.com (Mark Foley):
> >>> [...] I've downloaded and installed cryptsetup 2.7.5. [...]
> >>
> >> Most Linux distributions include cryptsetup in their repositories; you
> >> should not need to download and install it manually through
> >> out-of-band means. Using the distribution's packaged version is
> >> generally better unless you are working on the cryptsetup code; you
> >> get updates through the distribution's normal update process, and you
> >> don't risk unknowingly introducing incompatibilities between for
> >> example the kernel, libcryptsetup, and cryptsetup.
> > 
> > Michael, thanks for your prompt response. My distro (Slackware) does not ship
> > with cryptsetup
>
> AFAIK Slackware packages cryptsetup, at least in recent versions.
> While it is one of the oldest distros I know, it is not so generic :)
>
> Milan
>

You're right! I have cryptsetup 2.4.3 installed on Slackware. I didn't even try
checking for it before downloading 2.7.5

I guess "generic" depends on what one is used to. It does use the older rc.d
startup scripts, not systemd, but other than that, I don't find much difference
with e.g. Debian -- although it's been a while since I've used Debian. AFAIK
kernels and modules are not tweaked in any way for Slackware. Having using
Slackware without problems for the past 30 years as NAS servers, domain
controllers, etc., I'll probably stick with it until compelled to change (maybe
when Patrick Volkerding retires). 

Thanks for your feedback.

--Mark

Re: Using Windows and bitlocker

[Brian J. Murrell]

Jun. 19, 2025 6:55:59 p.m. Mark Foley <mfoley@novatec-inc.com>:
>
> The reason I am investigating this is because our insurer recommended that we
> encrypt the sensitive data on this Samba share.

Ahhhh.  "Recipe-book compliance".  I feel for ya.  It sounds like you are dealing with beauracrats that are just recommending/requiring things that they probably know nothing about, but it's out of a recipe book some "consultant" gave them and told them they should be requiring.  And they are doing it completely ignorant of your situation or context.  You are sadly a "tick-box" victim.  Completely unsurprising from the insurance industry.  Sadly.

Even more sadly, when you need to make a claim for something that has absolutely nothing to do with encrypting data-at-rest, they will ask you if you had at-rest encryption and when you say no, (even though your situation may have no real world requirement for at-rest encryption) they will deny your claim because you didn't tick an irrelevant tick box.  Insurance companies are the worst.

Cheers,
b.

Re: Using Windows and bitlocker

[Brian J. Murrell]

Jun. 19, 2025 5:53:07 p.m. Michael Kjörling <152cc69a347e@ewoof.net>:
> Microsoft's Bitlocker, LUKS on Linux, VeraCrypt, and others are
> examples of _full-disk encryption_ (FDE) solutions.

So while that is a common use-case, a full-disk (to encrypt) in the Linux context at least is just a block device.  Block devices don't have to be full disks though. They can be any of many partial disk abstractions whether that is partitions, LVM LVs, etc.

> Full-disk encryption is mainly about protecting _data at rest_. The
> typical example is if someone steals a laptop, or an external storage
> device used to hold backups. (It's also useful in other situations, of
> course.)

Indeed.  Again, the common example/use-case.  But I think there can be others.

I have occaisionally consdered a hybrid approach.

Imagine that I have data that I want encrypted at rest.  But I also don't want it mounted at boot because I want system boots to be succesful when unattended.  But I also don't want to "stash" the decryption key on the machine so that boots can happen unattended.  So what I really want is this encrypted-at-rest data to be (decrypted and) mounted on demand, like with autofs.

Further I imagine that each user authorized to decrypt the data has their own key (for revocation purposes) for the decryption.  A key that decrypts the master key for them.  I think LUKS already has this concept as "slots" doesn't it?

As I imagine this system, it reminds me roughly of how Kerberos works with users having a password to obtain a ticket-granting-ticket which then allows them to obtain crypto credentials for various services on various systems in the network.  A "key to obtain a key" kind of system.

This system I imagine also doesn't allow other users (such as root) access to the mounted data because it's mounted encrypted and is only available un-encrypted to the users that have keys for it.

This might all be very pie-in-the-sky thinking and not actually even technically be possible.  It's something I have somewhat-often imagined having.

Cheers,
b.