Is it possible to LUKS require both password and key file?
My goal is to be able easily destroy medium with key file in emergency situation and make system unbootable, even is potential advisor knows right password for the system. I'd store this key file in secure place and restore it after critical situation. I tried add key file using command # cryptsetup luksAddKey /dev/<device> but I didn't achieve what I want. I want to cryptsetup require both key file and password, not to boot system if one is provided. How can I achieve this in cryptsetup?
encryption disk-encryption cryptsetup
asked Feb 16 at 18:26
java-develjava-devel
298216
add a comment |
My goal is to be able easily destroy medium with key file in emergency situation and make system unbootable, even is potential advisor knows right password for the system. I'd store this key file in secure place and restore it after critical situation. I tried add key file using command # cryptsetup luksAddKey /dev/<device> but I didn't achieve what I want. I want to cryptsetup require both key file and password, not to boot system if one is provided. How can I achieve this in cryptsetup?
encryption disk-encryption cryptsetup
asked Feb 16 at 18:26
java-develjava-devel
298216
AFAIK LUKS works with just one password or keyfile provided, but requiring a login passphrase after LUKS is opened might be the closest I can think of. But I don't understand the goal listed first, how will a keyfile let you "destroy" the data (or the LUKS header)?
– Xen2050
Feb 17 at 1:16
1
see if your distro supports some flavor of encrypted keyfiles. then you need password (to decrypt keyfile) and keyfile in turn decrypts the LUKS partition. ( example wiki.gentoo.org/wiki/Custom_Initramfs#Encrypted_keyfile )
– frostschutz
Feb 17 at 16:46
add a comment |
My goal is to be able easily destroy medium with key file in emergency situation and make system unbootable, even is potential advisor knows right password for the system. I'd store this key file in secure place and restore it after critical situation. I tried add key file using command # cryptsetup luksAddKey /dev/<device> but I didn't achieve what I want. I want to cryptsetup require both key file and password, not to boot system if one is provided. How can I achieve this in cryptsetup?
encryption disk-encryption cryptsetup
asked Feb 16 at 18:26
java-develjava-devel
298216
My goal is to be able easily destroy medium with key file in emergency situation and make system unbootable, even is potential advisor knows right password for the system. I'd store this key file in secure place and restore it after critical situation. I tried add key file using command # cryptsetup luksAddKey /dev/<device> but I didn't achieve what I want. I want to cryptsetup require both key file and password, not to boot system if one is provided. How can I achieve this in cryptsetup?
encryption disk-encryption cryptsetup
encryption disk-encryption cryptsetup
asked Feb 16 at 18:26
java-develjava-devel
298216
asked Feb 16 at 18:26
java-develjava-devel
298216
asked Feb 16 at 18:26
java-develjava-devel
298216
asked Feb 16 at 18:26
java-develjava-devel
298216
asked Feb 16 at 18:26
java-develjava-devel
298216
298216
AFAIK LUKS works with just one password or keyfile provided, but requiring a login passphrase after LUKS is opened might be the closest I can think of. But I don't understand the goal listed first, how will a keyfile let you "destroy" the data (or the LUKS header)?
– Xen2050
Feb 17 at 1:16
1
see if your distro supports some flavor of encrypted keyfiles. then you need password (to decrypt keyfile) and keyfile in turn decrypts the LUKS partition. ( example wiki.gentoo.org/wiki/Custom_Initramfs#Encrypted_keyfile )
– frostschutz
Feb 17 at 16:46
add a comment |
AFAIK LUKS works with just one password or keyfile provided, but requiring a login passphrase after LUKS is opened might be the closest I can think of. But I don't understand the goal listed first, how will a keyfile let you "destroy" the data (or the LUKS header)?
– Xen2050
Feb 17 at 1:16
1
see if your distro supports some flavor of encrypted keyfiles. then you need password (to decrypt keyfile) and keyfile in turn decrypts the LUKS partition. ( example wiki.gentoo.org/wiki/Custom_Initramfs#Encrypted_keyfile )
– frostschutz
Feb 17 at 16:46
AFAIK LUKS works with just one password or keyfile provided, but requiring a login passphrase after LUKS is opened might be the closest I can think of. But I don't understand the goal listed first, how will a keyfile let you "destroy" the data (or the LUKS header)?
– Xen2050
Feb 17 at 1:16
AFAIK LUKS works with just one password or keyfile provided, but requiring a login passphrase after LUKS is opened might be the closest I can think of. But I don't understand the goal listed first, how will a keyfile let you "destroy" the data (or the LUKS header)?
– Xen2050
Feb 17 at 1:16
1
1
see if your distro supports some flavor of encrypted keyfiles. then you need password (to decrypt keyfile) and keyfile in turn decrypts the LUKS partition. ( example wiki.gentoo.org/wiki/Custom_Initramfs#Encrypted_keyfile )
– frostschutz
Feb 17 at 16:46
see if your distro supports some flavor of encrypted keyfiles. then you need password (to decrypt keyfile) and keyfile in turn decrypts the LUKS partition. ( example wiki.gentoo.org/wiki/Custom_Initramfs#Encrypted_keyfile )
– frostschutz
Feb 17 at 16:46
add a comment |
1 Answer
1
active
oldest
votes
You can create a detached LUKS header: a LUKS header metadata that is separate from the LUKS protected data, instead of being right before this data. Just put it on an external device like an USB key and you're set: if the external device is destroyed (and no backup available), there is no way to recover the data even by knowing the keyslot password.
From LUKS EXTENSION:
To specify a detached header, the
--headerparameter can be used in
all LUKS commands and always takes precedence over positional
parameter.
You should always refer to this device with some detected metadata (see below) rather than directly (eg: /dev/sdb), to avoid obvious fatal mistakes (and probably same for the data part). So for example, assuming you have an USB key identified like this when inserted and shown with ls:
lrwxrwxrwx. 1 root root 9 Feb 17 10:46 /dev/disk/by-id/usb-SomeBrand_SOMESERIAL -> ../../sdb
Creating the LUKS partition with detached header like this:
cryptsetup luksFormat /dev/datadevice --header /dev/disk/by-id/usb-SomeBrand_SOMESERIAL --verify-passphrase
will store the metadata (including the password protected master key) on the USB device. Of course you can choose to partition and format a filesystem on the USB key instead and have the header be a file on this filesystem. I'm trying to minimize dependencies for this example. You'd probably have to do this manually somehow at install time, because it's probably not supported by any installer.
There is now at least one difference: in this case by default there's no room before the data anymore, so /dev/datadevice can't even be detected as LUKS at all, which can be good (stealth) or bad (automatic scripts will have a harder time working to unlock it). You can still put a parameter to get the usual headroom (--align-payload 4096 (usually witnessed from using cryptsetup luksDump /dev/... | grep ^Payload on a normal LUKS) ) and then create first a fake (never used later) LUKS header there just for sake of detection if you really want.
You can then put the corresponding informations in /etc/crypttab:
myluksprotecteddata /dev/somedevice none luks,header=/dev/disk/by-id/usb-SomeBrand_SOMESERIAL
and/or unlock it directly with a cryptsetup command (just add the --header=/dev/disk/by-id/usb-SomeBrand_SOMESERIAL) option.
WARNING: compatibility with systemd, especially for booting, is not guaranteed.
answered Feb 17 at 16:25
A.BA.B
5,1271727
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "106"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f501076%2fis-it-possible-to-luks-require-both-password-and-key-file%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
You can create a detached LUKS header: a LUKS header metadata that is separate from the LUKS protected data, instead of being right before this data. Just put it on an external device like an USB key and you're set: if the external device is destroyed (and no backup available), there is no way to recover the data even by knowing the keyslot password.
From LUKS EXTENSION:
To specify a detached header, the
--headerparameter can be used in
all LUKS commands and always takes precedence over positional
parameter.
You should always refer to this device with some detected metadata (see below) rather than directly (eg: /dev/sdb), to avoid obvious fatal mistakes (and probably same for the data part). So for example, assuming you have an USB key identified like this when inserted and shown with ls:
lrwxrwxrwx. 1 root root 9 Feb 17 10:46 /dev/disk/by-id/usb-SomeBrand_SOMESERIAL -> ../../sdb
Creating the LUKS partition with detached header like this:
cryptsetup luksFormat /dev/datadevice --header /dev/disk/by-id/usb-SomeBrand_SOMESERIAL --verify-passphrase
will store the metadata (including the password protected master key) on the USB device. Of course you can choose to partition and format a filesystem on the USB key instead and have the header be a file on this filesystem. I'm trying to minimize dependencies for this example. You'd probably have to do this manually somehow at install time, because it's probably not supported by any installer.
There is now at least one difference: in this case by default there's no room before the data anymore, so /dev/datadevice can't even be detected as LUKS at all, which can be good (stealth) or bad (automatic scripts will have a harder time working to unlock it). You can still put a parameter to get the usual headroom (--align-payload 4096 (usually witnessed from using cryptsetup luksDump /dev/... | grep ^Payload on a normal LUKS) ) and then create first a fake (never used later) LUKS header there just for sake of detection if you really want.
You can then put the corresponding informations in /etc/crypttab:
myluksprotecteddata /dev/somedevice none luks,header=/dev/disk/by-id/usb-SomeBrand_SOMESERIAL
and/or unlock it directly with a cryptsetup command (just add the --header=/dev/disk/by-id/usb-SomeBrand_SOMESERIAL) option.
WARNING: compatibility with systemd, especially for booting, is not guaranteed.
answered Feb 17 at 16:25
A.BA.B
5,1271727
add a comment |
You can create a detached LUKS header: a LUKS header metadata that is separate from the LUKS protected data, instead of being right before this data. Just put it on an external device like an USB key and you're set: if the external device is destroyed (and no backup available), there is no way to recover the data even by knowing the keyslot password.
From LUKS EXTENSION:
To specify a detached header, the
--headerparameter can be used in
all LUKS commands and always takes precedence over positional
parameter.
You should always refer to this device with some detected metadata (see below) rather than directly (eg: /dev/sdb), to avoid obvious fatal mistakes (and probably same for the data part). So for example, assuming you have an USB key identified like this when inserted and shown with ls:
lrwxrwxrwx. 1 root root 9 Feb 17 10:46 /dev/disk/by-id/usb-SomeBrand_SOMESERIAL -> ../../sdb
Creating the LUKS partition with detached header like this:
cryptsetup luksFormat /dev/datadevice --header /dev/disk/by-id/usb-SomeBrand_SOMESERIAL --verify-passphrase
will store the metadata (including the password protected master key) on the USB device. Of course you can choose to partition and format a filesystem on the USB key instead and have the header be a file on this filesystem. I'm trying to minimize dependencies for this example. You'd probably have to do this manually somehow at install time, because it's probably not supported by any installer.
There is now at least one difference: in this case by default there's no room before the data anymore, so /dev/datadevice can't even be detected as LUKS at all, which can be good (stealth) or bad (automatic scripts will have a harder time working to unlock it). You can still put a parameter to get the usual headroom (--align-payload 4096 (usually witnessed from using cryptsetup luksDump /dev/... | grep ^Payload on a normal LUKS) ) and then create first a fake (never used later) LUKS header there just for sake of detection if you really want.
You can then put the corresponding informations in /etc/crypttab:
myluksprotecteddata /dev/somedevice none luks,header=/dev/disk/by-id/usb-SomeBrand_SOMESERIAL
and/or unlock it directly with a cryptsetup command (just add the --header=/dev/disk/by-id/usb-SomeBrand_SOMESERIAL) option.
WARNING: compatibility with systemd, especially for booting, is not guaranteed.
answered Feb 17 at 16:25
A.BA.B
5,1271727
add a comment |
You can create a detached LUKS header: a LUKS header metadata that is separate from the LUKS protected data, instead of being right before this data. Just put it on an external device like an USB key and you're set: if the external device is destroyed (and no backup available), there is no way to recover the data even by knowing the keyslot password.
From LUKS EXTENSION:
To specify a detached header, the
--headerparameter can be used in
all LUKS commands and always takes precedence over positional
parameter.
You should always refer to this device with some detected metadata (see below) rather than directly (eg: /dev/sdb), to avoid obvious fatal mistakes (and probably same for the data part). So for example, assuming you have an USB key identified like this when inserted and shown with ls:
lrwxrwxrwx. 1 root root 9 Feb 17 10:46 /dev/disk/by-id/usb-SomeBrand_SOMESERIAL -> ../../sdb
Creating the LUKS partition with detached header like this:
cryptsetup luksFormat /dev/datadevice --header /dev/disk/by-id/usb-SomeBrand_SOMESERIAL --verify-passphrase
will store the metadata (including the password protected master key) on the USB device. Of course you can choose to partition and format a filesystem on the USB key instead and have the header be a file on this filesystem. I'm trying to minimize dependencies for this example. You'd probably have to do this manually somehow at install time, because it's probably not supported by any installer.
There is now at least one difference: in this case by default there's no room before the data anymore, so /dev/datadevice can't even be detected as LUKS at all, which can be good (stealth) or bad (automatic scripts will have a harder time working to unlock it). You can still put a parameter to get the usual headroom (--align-payload 4096 (usually witnessed from using cryptsetup luksDump /dev/... | grep ^Payload on a normal LUKS) ) and then create first a fake (never used later) LUKS header there just for sake of detection if you really want.
You can then put the corresponding informations in /etc/crypttab:
myluksprotecteddata /dev/somedevice none luks,header=/dev/disk/by-id/usb-SomeBrand_SOMESERIAL
and/or unlock it directly with a cryptsetup command (just add the --header=/dev/disk/by-id/usb-SomeBrand_SOMESERIAL) option.
WARNING: compatibility with systemd, especially for booting, is not guaranteed.
answered Feb 17 at 16:25
A.BA.B
5,1271727
You can create a detached LUKS header: a LUKS header metadata that is separate from the LUKS protected data, instead of being right before this data. Just put it on an external device like an USB key and you're set: if the external device is destroyed (and no backup available), there is no way to recover the data even by knowing the keyslot password.
From LUKS EXTENSION:
To specify a detached header, the
--headerparameter can be used in
all LUKS commands and always takes precedence over positional
parameter.
You should always refer to this device with some detected metadata (see below) rather than directly (eg: /dev/sdb), to avoid obvious fatal mistakes (and probably same for the data part). So for example, assuming you have an USB key identified like this when inserted and shown with ls:
lrwxrwxrwx. 1 root root 9 Feb 17 10:46 /dev/disk/by-id/usb-SomeBrand_SOMESERIAL -> ../../sdb
Creating the LUKS partition with detached header like this:
cryptsetup luksFormat /dev/datadevice --header /dev/disk/by-id/usb-SomeBrand_SOMESERIAL --verify-passphrase
will store the metadata (including the password protected master key) on the USB device. Of course you can choose to partition and format a filesystem on the USB key instead and have the header be a file on this filesystem. I'm trying to minimize dependencies for this example. You'd probably have to do this manually somehow at install time, because it's probably not supported by any installer.
There is now at least one difference: in this case by default there's no room before the data anymore, so /dev/datadevice can't even be detected as LUKS at all, which can be good (stealth) or bad (automatic scripts will have a harder time working to unlock it). You can still put a parameter to get the usual headroom (--align-payload 4096 (usually witnessed from using cryptsetup luksDump /dev/... | grep ^Payload on a normal LUKS) ) and then create first a fake (never used later) LUKS header there just for sake of detection if you really want.
You can then put the corresponding informations in /etc/crypttab:
myluksprotecteddata /dev/somedevice none luks,header=/dev/disk/by-id/usb-SomeBrand_SOMESERIAL
and/or unlock it directly with a cryptsetup command (just add the --header=/dev/disk/by-id/usb-SomeBrand_SOMESERIAL) option.
WARNING: compatibility with systemd, especially for booting, is not guaranteed.
answered Feb 17 at 16:25
A.BA.B
5,1271727
edited Feb 18 at 13:38
answered Feb 17 at 16:25
A.BA.B
5,1271727
answered Feb 17 at 16:25
A.BA.B
5,1271727
answered Feb 17 at 16:25
A.BA.B
5,1271727
5,1271727
add a comment |
add a comment |
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f501076%2fis-it-possible-to-luks-require-both-password-and-key-file%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
AFAIK LUKS works with just one password or keyfile provided, but requiring a login passphrase after LUKS is opened might be the closest I can think of. But I don't understand the goal listed first, how will a keyfile let you "destroy" the data (or the LUKS header)?
– Xen2050
Feb 17 at 1:16
1
see if your distro supports some flavor of encrypted keyfiles. then you need password (to decrypt keyfile) and keyfile in turn decrypts the LUKS partition. ( example wiki.gentoo.org/wiki/Custom_Initramfs#Encrypted_keyfile )
– frostschutz
Feb 17 at 16:46