dmcrypt: เกิดอะไรขึ้นเมื่อ userspace crypto wrapper ไม่มีอยู่?


2

ฉันพยายามตั้งค่าโวลุ่มที่เข้ารหัสเพื่อจัดเก็บไฟล์อย่างปลอดภัย สิ่งนี้ทำในกระเป๋าของ NextThingCo แต่ระบบปฏิบัติการนั้นใช้เดเบียนดังนั้นฉันเดาว่าฉันจะลองที่นี่ก่อนเพราะคำถามของฉันเกี่ยวข้องกับ dmcrypt มากกว่าแพลตฟอร์มตัวเอง (หรือฉันคิดว่า)

สูตรที่ฉันสร้างขึ้นจนถึงตอนนี้มีดังต่อไปนี้ (อาจไม่ถูกต้องหรือซับซ้อนเกินไป):

  1. สร้างไฟล์
  2. ตั้งค่าเป็นอุปกรณ์วนซ้ำ
  3. ทำเซพอัปสำหรับการจัดรูปแบบและเปิด "abc" เป็นรหัสผ่านที่ป้อนผ่าน stdin (ข้อสันนิษฐานนี้ถูกต้องหรือไม่)
  4. ทำระบบไฟล์
  5. ภูเขา

ดังนั้นดูเหมือนว่านี้:

 sudo dd if=/dev/urandom of=./encrypted.volume bs=512K count=200
 sudo losetup /dev/loop0 ./encrypted.volume  
 echo "abc" | sudo cryptsetup luksFormat /dev/loop0
 echo "abc" | sudo cryptsetup open /dev/loop0 vault
 sudo mkfs /dev/mapper/vault
 sudo mount /dev/mapper/vault /mnt/vault

ตอนนี้ทั้งหมดนี้ดูเหมือนว่าจะทำงานได้ดีและสวยงามนั่นคือจนกว่าฉันจะใช้พารามิเตอร์ --debug (ฉันต้องการลองพารามิเตอร์อื่น ๆ เช่นขนาดคีย์) และฉันก็ตระหนักถึงข้อความต่อไปนี้:

# cryptsetup 1.7.0 processing "cryptsetup -v --debug --cipher aes-xts-plain64 --key-size 
512 --hash sha512 --iter-time 5000 --timeout 10 --use-random luksFormat /dev/loop0"
# Running command luksFormat.
...
# Userspace crypto wrapper cannot use aes-xts-plain64 (-95).
...
device-mapper: remove ioctl on temporary-cryptsetup-6661 failed: Device or resource busy    <------ appears when I change the  --key-size to 512 i.s.o. default 256
...
device-mapper: remove ioctl on temporary-cryptsetup-6698 failed: Device or resource busy

ฉันพยายามรันเกณฑ์มาตรฐานด้วย:

chip@chip:~/data/run$ sudo cryptsetup --debug benchmark
[sudo] password for chip:
# cryptsetup 1.7.0 processing "cryptsetup --debug benchmark"
# Running command benchmark.
# Installing SIGINT/SIGTERM handler.
# Unblocking interruption on signal.
# Tests are approximate using memory only (no storage IO).
# Crypto backend (gcrypt 1.6.4) initialized in cryptsetup library version 1.7.0.
# Detected kernel Linux 4.4.13-ntc-mlc armv7l.
# KDF pbkdf2, hash sha1: 59041 iterations per second (256-bits key).
PBKDF2-sha1        59041 iterations per second for 256-bit key
# KDF pbkdf2, hash sha256: 79437 iterations per second (256-bits key).
PBKDF2-sha256      79437 iterations per second for 256-bit key
# KDF pbkdf2, hash sha512: 40705 iterations per second (256-bits key).
PBKDF2-sha512      40705 iterations per second for 256-bit key
# KDF pbkdf2, hash ripemd160: 50412 iterations per second (256-bits key).
PBKDF2-ripemd160   50412 iterations per second for 256-bit key
# KDF pbkdf2, hash whirlpool: 7481 iterations per second (256-bits key).
PBKDF2-whirlpool    7481 iterations per second for 256-bit key
# Cannot initialise cipher aes, mode cbc.
Required kernel crypto interface not available.
Command failed with code 95: Operation not supported

นี่คือข้อมูลเพิ่มเติมบางอย่างเกี่ยวกับแพลตฟอร์มและระบบปฏิบัติการ:

chip@chip:~/data/run$ uname -r
4.4.13-ntc-mlc
chip@chip:~/data/run$ cat /boot/config-4.4.13-ntc-mlc | grep CRYPTO_USER_API_SKCIPHER
# CONFIG_CRYPTO_USER_API_SKCIPHER is not set

ฉันเข้าใจว่าฉันจะต้องคอมไพล์เคอร์เนลใหม่หลังจากฉันตั้งค่า CONFIG_CRYPTO_USER_API_SKCIPHER เพื่อให้ userspace crypto API พร้อมใช้งาน ฉันไม่คิดว่าจะมีวิธีการที่จะมีหรือไม่

ฉัน LuksDump ข้อมูลเกี่ยวกับไฟล์จัดเก็บข้อมูล:

chip@chip:~/data/run$ sudo cryptsetup luksDump ./encrypted.volume

LUKS header information for ./encrypted.volume

Version:        1
Cipher name:    aes          <------- ???
Cipher mode:    xts-plain64  <------- ???
Hash spec:      sha256       
Payload offset: 4096
MK bits:        256
MK digest:      ee f8 8d ad 9b 67 d9 7d cb 20 fe a9 25 a3 8b a5 c2 65 56 dd
MK salt:        38 74 e8 9d 77 6a 93 b5 03 41 cb 3e ce 79 b4 00
                55 f3 98 8f c5 a7 14 05 25 9c 4e 91 68 1a 53 37
MK iterations:  18500
UUID:           36912ea4-9adb-4d1f-b9f2-f6a09a258833

Key Slot 0: ENABLED
        Iterations:             150587
        Salt:                   e8 4f f3 c1 07 1a 2b 2d d2 d9 f4 55 0f b3 13 28
                                2a 69 06 aa a0 94 4a 05 5d 5f e9 28 9b 91 39 94
        Key material offset:    8
        AF stripes:             4000
Key Slot 1: DISABLED
Key Slot 2: DISABLED
Key Slot 3: DISABLED
Key Slot 4: DISABLED
Key Slot 5: DISABLED
Key Slot 6: DISABLED
Key Slot 7: DISABLED

อย่างไรก็ตามฉันมีคำถามสองสามข้อเกี่ยวกับสถานการณ์ปัจจุบัน:

  • พาร์ติชันเข้ารหัสลับจริง ๆ หรือไม่ ถ้าเป็นเช่นนั้นโครงการไหน?
    • วิธีตรวจสอบในบรรทัดคำสั่ง? พยายามที่จะถ่ายโอนข้อมูลเกี่ยวกับพาร์ทิชันบอกฉันว่า "มีส่วนหัว LUKS" แต่นั่นไม่ได้บอกฉันว่าข้อมูลถูกเข้ารหัสหรือไม่
  • วิธีแก้ไขสถานการณ์ '' ทรัพยากรไม่ว่าง '' ซึ่งจะให้ฉันใช้ขนาดคีย์ 512 ได้อย่างไร

ขอบคุณสำหรับการอ่านทุกอย่างที่นี่ พอยน์เตอร์ใด ๆ จะได้รับการชื่นชมอย่างมาก

แก้ไข (08/12/17): - บรรทัดสุดท้ายของ crypsetup --help:

<name> is the device to create under /dev/mapper
<device> is the encrypted device
<key slot> is the LUKS key slot number to modify
<key file> optional key file for the new key for luksAddKey action

Default compiled-in key and passphrase parameters:
        Maximum keyfile size: 8192kB, Maximum interactive passphrase length 512 (characters)
Default PBKDF2 iteration time for LUKS: 2000 (ms)

Default compiled-in device cipher parameters:
        loop-AES: aes, Key 256 bits
        plain: aes-cbc-essiv:sha256, Key: 256 bits, Password hashing: ripemd160
        LUKS1: aes-xts-plain64, Key: 256 bits, LUKS header hashing: sha256, RNG: /dev/urandom

คำตอบ:


0

ดูเหมือนว่าเคอร์เนลของคุณไม่รองรับคีย์ 512 บิตด้วย aes-xts-plain64 และไม่ได้ทำโหมด aes cbc เลย:

# Cannot initialise cipher aes, mode cbc.
Required kernel crypto interface not available.
Command failed with code 95: Operation not supported

แต่นั่นเพิ่งหยุดมาตรฐาน xts เป็นที่ต้องการมากกว่า cbc ต่อไป ฉันคิดว่าคุณสามารถใช้โหมดเพิ่มเติมได้โดยสร้างใหม่ / รับเคอร์เนลใหม่ (หรืออาจจะดัดแปลง, ฉันไม่แน่ใจ 100%)

มีข้อมูลที่ขัดแย้งกันเล็กน้อยเกี่ยวกับ aes ด้วยคีย์ 512 บิต, q นี้บน crypto.SE บอกว่าทำไมเราไม่สามารถใช้ขนาดคีย์ AES 512 ได้? และสรุปว่ามันไม่ได้ถูกกำหนด / รองรับ แต่ใช้--cipher aes-xts-plain64 --key-size 512งานได้ดีสำหรับ cryptsetup ของฉัน (v1.7.3) และ my / proc / crypto ของฉันมีรายการ xts (aes) ที่รองรับการใช้งานคีย์ขนาด 32-64 ไบต์

  • อย่างไรก็ตามจาก luksDump ./encrypted.volumeไฟล์นั้นจะถูกเข้ารหัสด้วย aes ในโหมด xts-plain64 (aes-xts-plain64) อย่างน้อยสิ่งที่เขียนถึงมันจะถูกเข้ารหัสมันจะไม่ถูกแตะต้องหากคุณไม่ได้ luksOpen-ed และเขียนถึงมัน
  • ./encrypted.volume ไม่ใช่พาร์ติชั่นดิสก์แยกต่างหากมันเป็นเพียงไฟล์ / คอนเทนเนอร์
  • คุณจะใช้เอนโทรปีของคุณจำนวนมากddเพื่อใช้ 100M (512 * 200?) จาก / dev / urandom และไม่จำเป็น การสร้างไฟล์คอนเทนเนอร์โดยใช้ศูนย์เป็นเรื่องปกติ (หรือเพียงแค่fallocate) เมื่อมัน luksFormatted แล้วคุณเติมด้วยศูนย์ซึ่งจะได้รับการเข้ารหัสและเขียนลงดิสก์

  • 10 บรรทัดสุดท้ายของcryptsetup --helpอะไร? มันจะบอกว่าค่าเริ่มต้นคืออะไร
  • มีอะไรบ้าง/proc/crypto? มันจะแสดงให้คุณเห็นวิธีการเข้ารหัสที่มีอยู่
  • cryptsetup ล่าสุดของตัวเองด้วยดังนั้นคุณสามารถข้าม losetup และปล่อยให้ cryptsetup จัดการมันได้
  • หากเชลล์ของคุณบันทึกประวัติข้อความรหัสผ่าน ("abc") ของคุณอาจถูกเก็บไว้ในรูปแบบธรรมดานั่นก็ไม่ได้ยอดเยี่ยม มันอาจจะมองเห็นได้psเช่นกันถ้ามันแสดงรายการบรรทัดคำสั่งแบบเต็ม การใช้วิธีอื่นในการรับข้อความรหัสผ่านไปยัง stdin อาจปลอดภัยกว่าหรือใช้ keyfile บนสื่อที่ปลอดภัย (อุปกรณ์ USB ภายนอก /) หรือใน ramfs เป็นต้นดู 2.14 ในคำถามที่พบบ่อย

ขอบคุณสำหรับคำแนะนำ ฉันจะเพิ่มข้อมูลในโพสต์ดั้งเดิมของฉัน ด้วยสัญลักษณ์แสดงหัวข้อแรกของคุณ: Anyway, from luksDump the ./encrypted.volume file looks encrypted with aes in mode xts-plain64 (aes-xts-plain64). At least anything written to it would be encrypted, it'll be untouched if you haven't luksOpen-ed and written to it. คุณหมายถึงที่เข้ารหัสลับ. เข้ารหัสลับจริง ๆ แล้วแม้ว่าจะไม่มี API ผู้ใช้งานหรือไม่ ฉันกังวลว่าส่วนหัวของ Luks พูดอย่างหนึ่ง แต่การเข้าถึงข้อมูลกำลังทำอย่างอื่น เช่นข้อความธรรมดา r / w
Paco

หลังจากอ่านลิงค์ฉันเปลี่ยนสูตรดังนี้: การ sudo dd if=/dev/zero of=quick.volume bs=512K count=100 sudo losetup -f sudo losetup /dev/loop0 quick.volume echo "abc" | sudo cryptsetup --debug luksFormat /dev/loop0 echo "abc" | sudo cryptsetup --debug open /dev/loop0 quick sudo dd if=/dev/zero of=/dev/mapper/quick echo "abc" | sudo cryptsetup --debug close quick hexdump quick.volume อ่าน hexdump ฉันเห็นข้อมูลที่อ่านไม่ออกหลังจาก 2MB ดังนั้นฉันคิดว่ามันเข้ารหัสจริง แต่ด้วยรหัสใด ฉันควรจะเชื่อ luksDump หรือไม่โดยพูดว่า xts-plain64 แม้ไม่มี API ผู้ใช้
Paco

2MB มักจะมีขนาดของส่วนหัว LUKS และข้อมูลที่เข้ารหัสเริ่มต้นหลังจากดังนั้นข้อมูลที่อ่านไม่ออกดูเหมือนจะเป็นรหัสที่ตกลง ฉันเชื่อว่า luksDump ของ cryptsetup หรือในขณะที่เปิดคุณสามารถตรวจสอบได้dmsetupเช่นกันมันจะแสดงคีย์การเข้ารหัสที่แท้จริง ( fyi สามารถเพิ่มข้อความรหัสผ่านใหม่โดยไม่ทราบว่ามีอยู่ ) ดูเหมือนว่าcrypto API ของเคอร์เนลทำงานได้ดี cryptsetup ก็โอเคแค่ aes-
cbc

ในที่สุดฉันใช้dmsetupเพื่อตรวจสอบไฟล์ที่เข้ารหัส ผลที่ได้คือ: chip@chip:~$ sudo dmsetup table --showkeys /dev/mapper/quick 0 98304 crypt aes-xts-plain64 <32BYTENUMBER> 0 7:0 4096 ตอนนี้ฉันมั่นใจมากขึ้นว่าข้อมูลของฉันถูกเข้ารหัส ขอบคุณสำหรับความช่วยเหลือ!
Paco

ยินดีต้อนรับ :) ฉันมีความคิดอื่นคุณสามารถสร้างที่เก็บ LUKS ขนาดเล็กบนคอมพิวเตอร์เครื่องอื่นและดูว่ามันถูกอ่านและเขียนลงในระบบนี้จากนั้นนำกลับไปที่คอมพิวเตอร์เครื่องอื่น & ตรวจสอบข้อมูลใหม่หรือในทางกลับกัน
Xen2050
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.