drive-trust-alliance / sedutil Goto Github PK

So I am currently dual booting Windows and Arch Linux on my desktop system.

/dev/sda is the drive where Linux is installed. Single partition

/dev/sdb is the drive where Windows is installed. the EFI partition is located on /dev/sdb2

I want to encrypt /dev/sda but Im having some issues. I follow the instructions on the wiki here but when I power on the system I am never asked for a password and Archlinux fails to boot and throws me to a rescue CLI prompt, indicating that it's unable to find the UUID for the root partition.

So a couple of questions:

I've run:

sedutil-cli --initialsetup <password> /dev/sda
sedutil-cli --loadPBAimage <password> <pba_file> /dev/sda
sedutil-cli --setMBREnable on <password> /dev/sda

sedutil-cli --enableLockingRange 0 <password> /dev/sda

However, I dont really understand how the UEFI bootloader (on /dev/sdb2) can know about the encryption state of /dev/sda, or when the decryption prompt is supposed to be triggered. Do I need to do anything with /dev/sdb as well here? Or do I have to add some logic to the bootloader somehow?

Thanks for any help!

sedutil should use a password prompt rather than having the password inline with the command. This prevents the password from entering log files like .bash_history
Whilst one can delete .bash_history some organizations may be required to keep it intact for auditing purposes (I would personally like my sedutil logged so I can demonstrate that I maintain it, but don't want my password in it).

I just pulled the repo to go through it and tinker with it, and look for every case where this can be inserted, but for now this issue thread can be a starting point.

Cheers,
-H

When I run sedutil-cli on the Rescue image I get the following error:

sedutil-cli: /usr/lib/libstdc++.so.6: version 'GLIBCXX_3.4.21' not found (required by sedutil-cli)

The issue again is on my Arch linux machine, but eventually it will bite you later. The problem is that we are building the sedutil-cli by using system gcc, while at the same time we are relying on the TinyCore (built with different gcc).

In my case, obviously libstdc++ is newer and the 'GLIBCXX_3.4.21' is missing on the syslinux image.

My suggestion is to build the sedutil-cli statically. The executable will become 2.4M.

diff --git linux/CLI/nbproject/Makefile-Release_i686.mk linux/CLI/nbproject/Makefile-Release_i686.mk
index a93b927..eabc01b 100644
--- linux/CLI/nbproject/Makefile-Release_i686.mk
+++ linux/CLI/nbproject/Makefile-Release_i686.mk
@@ -73,7 +73,7 @@ FFLAGS=-Wall
 ASFLAGS=

 # Link Libraries and Options
-LDLIBSOPTIONS=
+LDLIBSOPTIONS=-static

 # Build Targets
 .build-conf: ${BUILD_SUBPROJECTS}

Doing so, the program now runs correctly.

The same patch is required for the UEFI64 image:

diff --git linux/CLI/nbproject/Makefile-Release_x86_64.mk linux/CLI/nbproject/Makefile-Release_x86_64.mk
index b9ce233..3d0a679 100644
--- linux/CLI/nbproject/Makefile-Release_x86_64.mk
+++ linux/CLI/nbproject/Makefile-Release_x86_64.mk
@@ -73,7 +73,7 @@ FFLAGS=-Wall
 ASFLAGS=

 # Link Libraries and Options
-LDLIBSOPTIONS=
+LDLIBSOPTIONS=-static

 # Build Targets
 .build-conf: ${BUILD_SUBPROJECTS}

Got inspiration from this post, which lacks clear steps to get it working: http://www.tonymacx86.com/mavericks-desktop-support/176366-tcg-opal-os-x-working-free-hardware-encryption-paranoid.html

I'm stuck at the step Installing the msed PBA in this guide: https://vxlabs.com/2015/02/11/use-the-hardware-based-full-disk-encryption-your-tcg-opal-ssd-with-msed/

What would be the equivalent option on osx El Capitan?

Is it possible to use the sedutil command from inside linux on a mac osx ssd drive (850 EVO)?

I want to give the Range1's access to user1.User1 can only manipulate range1.

The following is my step:
first,initialSetup password device
second,enableLockingRange 0 password device
third,setupLockingRange 1 1 2000000 password device
fourth,enableLockingRange 1 password device
fifth,poewer off the device
sixth,poewer on the device
seventh,diseLockingRange 1 password device
eighth,setMBRDone on
To this, I should be able to unlock LockingRange1,I think.
But I'm puzzled how to use user1 and above LockingRange1 is not unLocking.
Who can answer ,thank you!!!

I got referred here by r0m30/msed#31, so I need either a compiled version of everything, or instructions, how to build it myself.

According to the wiki, there should be a file called script-to-build-pba inside images directory:

cd /dir/containing/sedutil-cli cd images sudo ./script-to-build-pba

Unfortunately this file is missing, so I have to do a wild guess which script to build first, in order to match the "-f" exists checks.

Can you please (re)introduce the missing file - it will be a lot easier to build the sedutil (under Linux)?

On additional thing, regarding the documentation - I had to run multiple times the build process over and over again till I install all prerequisites that were missing on my PC.

Under Arch Linux, except for the mandatory base-devel package I had to install the following:

nasm asciidoc rsync cpio

It would be great if you list in the documentation, the pre-required builder tools - at least for one of the major distributions, like Ubuntu. I don't need to be Arch Linux.

Seagate ST91000642SS 1TB SED SATA HDD.

Hi, I am unable to revert a Segate SED HDD. 1st attempt produces:

• 16:21:52.253 ERR : method status code INVALID_FUNCTION

A 2nd attempt produces:

• 16:22:11.933 ERR : method status code SP_BUSY
• 16:22:11.933 ERR : Session start failed
• 16:22:11.958 ERR : One or more header fields have 0 length
• 16:22:11.958 ERR : EndSession Failed

Also, a --scan doesn't show yes or no, but "E":

/dev/sdb E ST91000642SS 0004

--query shows:

Locking function (0x0002)
Locked = N, LockingEnabled = Y, LockingSupported = Y, MBRDone = N, MBREnabled = N, MediaEncrypt = Y

Both verbose outputs attached. Note that the command works fine on a Hitachi drive.

sed-invalidfunction.txt
sed-sp_busy.txt

I want to add user1 authorization to unlock lockingrange0.
Who can give me some advice, ideas, or reference documentation?
Thank you!!!

I believe the humans who used samsung hard disk may know the encryption tool-EMBASSY Security Center. I also want to achieve to increase users like this tool .

First, thank you very much for this great tool and your hard work.

My drive: Crucial M550 512GB (CT512M550SSD1)
System: ASUS L50VN-AK005C (90NSLA8241113CAC451)

I have some trouble setting up custom locking ranges using the Rescue.img.gz.

For example, I just want to set up LR1 (or other locking ranges) to protect my mbr and partition table with the following command (after successful reverttper and initialsetup):
sedutil-cli setupLockingRange 1 0 2047 mylongpassword /dev/sda

Unfortunately, the command fails with some error messages:
method status code INVALID_PARAMETER
setupLockingRange Failed

Some instructions or an article under the Wiki section about locking ranges (setup) would be useful.

Again, thank you very much.

I'm having an issue unlocking the Samsung 850 Pro after locking it. I followed the instructions at the "Encrypting Your Drive" page. I'm using Ubuntu 14.04 on a drive and connecting the drive with an external eSata port.

1. First I ran "./sudo sedutil -–initialsetup PASSWORD /dev/sdb"
2. Since this is not a boot drive, I then ran "./sudo sedutil --enableLockingRange 0 PASSWORD /dev/sdb"
3. These commands seem to run successfully so I reboot the laptop, but the drive seems to still be unlocked after rebooting.

I was hoping that since I was not using this as a boot drive, I would be able to run the --disableLockingRange command to unlock the drive and access contents. I thought that the --loadPBAimage and --setMBREnable commands weren't used since the drive is not a boot drive.

sedutil-cli.exe - System Error

The program can't start because MSVCP140.dll is missing from your computer. Try reinstalling the program to fix this problem.

OK

PS - there's no Issues option in /exec, so I posted in the issues repository for /sedutil.

Hi,

I am keen to use your solution on my Samsung 850 EVO but am wondering what the risk of brute force is.

1. Does the drive's controller throttle attempts and/or requires power cycles every x failed attempts?

2. What length password would be recommended to provide decent protection in the event of theft?

Thanks a lot

I'm attempting to unlock a Samsung 850 Pro drive on Windows 7 which I locked in Ubuntu using sedutil. However, sedutil on windows does not seem to recognize my drive as being Opal compliant. When I run a scan command the "PhysicalDrive1" which I determined to be the Samsung SSD is not recognized as an Opal drive. Also when I query the drive it says that the drive is unsupported.

Even when I revert to factory defaults using the PSID command in Ubuntu, sedutil on Windows still does not recognize the drive as being an Opal device.

I also tried only running initialsetup without enabling a locking range and I still had the same issue.

I'm connecting to the drive using an external esata port on the laptop which I unplug and re-plug in to cycle power when needed. I'm attempting to log into the drive "post-boot", so I am running the commands using the sedutil-cli.exe executable.

Hi!
First thanks for this software.
I would like to test it but I can't. I dont know why my Samsung 850 Pro (connected through sata3 controller (on Marvell 88se9230 chipset)) is not recognized on my setup (windows 7).

sedutil-cli --scan

Scanning for Opal compliant disks
.\PhysicalDrive0 No
.\PhysicalDrive1 No
.\PhysicalDrive2 No
.\PhysicalDrive3 No
No more disks present ending scan

sedutil-cli --query .\PHYSICALDRIVE1

• 23:34:46.000 ERR : Invalid or unsupported disk .\PHYSICALDRIVE1

.\PHYSICALDRIVE1 - is my samsung

info from wmic diskdrive list

Volume0 .\PHYSICALDRIVE0 IDE\DISKVOLUME01.0.00__\4&19FEAA6C&0&0.0.0

Samsung SSD 850 PRO 256G SCSI Disk Device .\PHYSICALDRIVE1 SCSI\DISK&VEN_SAMSUNG&PROD_SSD_850_PRO_256G\5&E93270A&2&000000

SanDisk Cruzer Micro USB Device .\PHYSICALDRIVE3 USBSTOR\DISK&VEN_SANDISK&PROD_CRUZER_MICRO&REV_8.01\2243300C54E2CCFF&0

USB Flash DISK USB Device .\PHYSICALDRIVE2 USBSTOR\DISK&VEN_USB&PROD_FLASH_DISK&REV_1100\1412045090058834&0

Hello,
as I already mentioned in the:

#37

I found another command formatting bug on Test-the-Rescue-system guide page:

https://github.com/Drive-Trust-Alliance/sedutil/wiki/Test-the-Rescue-system

The commands:

sedutil-cli –scan
sedutil-cli –query /dev/sda <== chose an OPAL compliant device

throws the command formatting bug:

ERR : Argument 1 (-scan) should be a command

as on the screnshoot:

Because correctly should be "--scan" & "--query" (double minus sing) as on the screenshoot:

[Edit] I also found another formatting bugs (a little different) on PSID Revert system Wiki page:

https://github.com/Drive-Trust-Alliance/sedutil/wiki/PSID-Revert

For example if you take a look at any of the commands there like:

1. sedutil-cli -–scan <- SCAN to find Opal Drive (you should a 1 or 2 next the the drive)

you see the

-–

(before the "scan")

is malformed like on the screenshoot:

(the first of the minus signs is different than the second one, the first is too short, and the second is too long) thus sometimes when copy & paste to Windows dos command prompt, one of the minus signs gets malformed, and the whole command throws the command formating error - the same like in Test-the-Rescue-system guid page case.

OK -- I've messed around with this a bit, and looked on the older msed github area, and this newer project under Drive-Trust-Alliance. I almost have everything worked out, but I'm having one last (I think) issue. I have had a bit of trouble with the documentation as some of the stuff on the DTA area still points back to the old msed repository. Minimal Background:

This is a Dell Latitude E7450, that came with Ubuntu 14.04 pre-installed. I've managed to boot/minimal test the Rescue image using Legacy (BIOS) boot mode. I was able (after manually creating a boot entry with proper \BOOT\efi\bootx64.efi filename) to boot the UEFI64_Release image off of USB to test. I then loaded that PBA, enabled MBR, setLockingEnable on, etc... I am able to boot the laptop and get to the PBA where the password is asked for. I can tell I'm entering the right password as I get no errors printed (which do show up with bogus password) -- but at this step where the PBA should be booting the original Linux install, it fails. I haven't been able to tell exactly what it is doing, but it eventually just comes around and reboots into the PBA.

I can boot off the rescue image, turn MBR off, and disable the locking range and can then boot into my normal ubuntu setup. What is supposed to happen after the PBA is authenticated? How does boot order come into play? I think that after the PBA is done, a reboot effectively happens (but at this point with the drive unlocked), is that right? If so, shouldn't that be the equivalent of booting normally after having used rescue mode to disable the locking, and rebooting at that point?

It seems like after the PBA reboot, the system finds no valid bootable image. It also appears to me that the laptop actually cycles power (the power LED goes off) during the reboot. Could that be happening? If so, I'm guessing the disk would still be locked at that point and no valid OS would be found.

Any ideas?

I want to test the PBA image. Below is my test steps:
first,I follow https://github.com/Drive-Trust-Alliance/sedutil/wiki/Encrypting-your-drive .I do
PS C:\Users\admin\Desktop\TCG\sedutil-master_2\windows\CLI\x64\Debug> .\sedutil-cli.exe --initialSetup 12345678 .\PhysicalDrive0

• 19:39:13.000 INFO: takeOwnership complete
• 19:39:13.484 INFO: Locking SP Activate Complete
• 19:39:14.984 INFO: LockingRange0 disabled
• 19:39:14.468 INFO: LockingRange0 set to RW
• 19:39:15.953 INFO: MBRDone set on
• 19:39:15.422 INFO: MBRDone set on
• 19:39:16.890 INFO: MBREnable set on
• 19:39:16.890 INFO: Initial setup of TPer complete on .\PhysicalDrive0
  PS C:\Users\admin\Desktop\TCG\sedutil-master_2\windows\CLI\x64\Debug> .\sedutil-cli.exe --loadPBAimage 12345678 C:\Users\admin\Desktop\UEFI64\UEFI64_D
  ebug-1.12.img .\PhysicalDrive0
• 19:40:58.000 INFO: Writing PBA to .\PhysicalDrive0
  / [*********************] 7341056 bytes written
• 19:51:32.266 INFO: PBA image C:\Users\admin\Desktop\UEFI64\UEFI64_Debug-1.12.img written to .\PhysicalDrive0
  PS C:\Users\admin\Desktop\TCG\sedutil-master_2\windows\CLI\x64\Debug> .\sedutil-cli.exe --setMBREnable on 12345678 .\PhysicalDrive0
• 19:53:17.000 INFO: MBRDone set on
• 19:53:17.484 INFO: MBREnable set on
  PS C:\Users\admin\Desktop\TCG\sedutil-master_2\windows\CLI\x64\Debug> .\sedutil-cli.exe --enableLockingRange 0 12345678 .\PhysicalDrive0
• 19:53:37.000 INFO: LockingRange0 enabled ReadLocking,WriteLocking
  PS C:\Users\admin\Desktop\TCG\sedutil-master_2\windows\CLI\x64\Debug

second,I restart the computer.On the first screen, I start hotkey press F8,popup boot menu options, choose from Samsung SSD 850 EVO disk. Press the enter key, the computer automatically restart.

I think the PBA should ask for my password, but there is nothing. As before to restart the computer, and not to enter the PBA. I don't know why. Is my operation error? what did not operate else?
My disk is Samsung SSD 850 EVO.
My operating system is Windows 8.1,64-bit
I load UEFI64 PBA to unzip UEFI64_Debug-1.12.img.

Hello,

I've already installed the "regular" PBA on my Samsung Evo drive running Windows, and everything is working just great. Now I discovered there's a "Small Lean PBA" as well, I've tried testing it by putting in on a USB stick first, but when I do, entering a password on bootup gets me the following error:

"found device identify failed"

I went ahead and turned off locking and the original PBA as described on the bottom of your "Encrypting your drive" page, but it makes no difference. Does this simply mean the "Small Lean PBA" won't work on my machine, or is there something else I can try?

Thanks (above all for the hard work you are putting into this - fantastic!)

Tested on:
Lenovo T520
Samsung 850 EVO EMT01B6Q
After entering any fake password in password query, a message flashes followed by reboot. I managed to get the massage by taking a video of the process. Screenshot of the video attached.

Since I don't have the build script that build everything, including the msed/sedutil/linux I had to do the following to build both Debug and Release versions:

cd msed/sedutil/linux/CLI
sudo make all

Unfortunately this journey ended with missing Version.h errors. I did a patch that basically does exactly what is done for "build" target in the Makefile.

Unfortunately the "build" target builds only Debug target which prevents me of building the entire buildrescue. Once I've fixed the make all, now I can build the buildrescue.

As I've already mentioned on the other bug report - it would be great if you find time to update the documentation about the building of all files. Thanks!

getversion.patch.zip

I've tried to get the UEFI PBA working on an USB stick (to see if it's actually working before writing it to the SSD). The UEFI recognizes it, but then the following error occurs (again and again, it's seems to loop): loading bzImage ... failed IO error. I don't think that the USB stick is the problem because it worked totally fine with other USB distros.

In the conf file I had to fix the TINYCORE to Core-current.iso because http://distro.ibiblio.org/tinycorelinux/6.x/x86/ doesn't contain the hard-coded version anymore (maybe you can take the old one from the "archive" directory or use the current.iso).

The other problem I have is maybe due to different versions of the fdisk. On my machine

fdisk -v
fdisk from util-linux 2.27.1

skips one of the steps (might be harmless):

~/msed/sedutil/images/biospba$ sudo fdisk -C 10 biospba-1.10-dirty.img

Welcome to fdisk (util-linux 2.27.1).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.

Device does not contain a recognized partition table.
Created a new DOS disklabel with disk identifier 0xa072777f.

Command (m for help): h

Command (m for help): o

Created a new DOS disklabel with disk identifier 0x389aeee2.

Command (m for help): n
Partition type
p primary (0 primary, 0 extended, 4 free)
e extended (container for logical partitions)
Select (default p): p
Partition number (1-4, default 1): 1
First sector (1-2047, default 1): 63
Last sector, +sectors or +size{K,M,G,T,P} (63-2047, default 2047):

Created a new partition 1 of type 'Linux' and of size 992.5 KiB.

Command (m for help): a
Selected partition 1
The bootable flag on partition 1 is enabled now.

Command (m for help): 1
1: unknown command

Command (m for help): t

Selected partition 1
Partition type (type L to list all types): b
Changed type of partition 'Linux' to 'W95 FAT32'.

Command (m for help): w
The partition table has been altered.
Syncing disks.

Obviously the "1" command is not recognized in that context!

Edit: I see the same issue with buildrescue - it seems after setting the active partition ("a") you don't need to pass "1"?

followed the install procedure
rebooted. no PBA showed up, instead i had a no boot device found
i suspect this happened because i used the uefi 64 pba on w7 machine
i was deceived by an hidden option in my bios called compatibility mode that simulates a uefi environment to allow dual booting w7 and w8
anyway i figured i could still use the pba on my usb device, i did and it worked, i got to my desktop no problems.
then i screwed up, enabled bios autentication, figured why the heck not extra layer of security cant be too bad... turns out it was the worst possible thing i could do, enabling bios autentication on a samsung 840 evo compatible system turns on the built in device encryption, found out about this reading about samsung magician security options: OPAL and bios passwords are mutually exclusive and should never be used toghether.

i disabled the additional password immediatly but now neither the PBA on my usb neither the one on my ssd work and windows goes into BSOD midway through the boot process, i suppose the reason for this is the drive is still sedutil locked.

so then i used the rescue image to disable the locking and it did something, now i can boot into safe mode, however whenever i try to boot in normal mode my system crashes like it uses to.

running out of options can anyone help me unfu* my system ?
can i unload the wrong pbaimage from my drive to load the other one ?

I have not been able to get any parts of sedutil to work.

I have a Lenovo Y700 Touch-15ISK on which I have installed a Samsung PM951, which uses NVMe.

I am using the copy of sedutil-cli from sedutil_LINUX.tgz and UEFI64_Release.img from UEFI64_Release.img.gz that are linked from https://github.com/Drive-Trust-Alliance/sedutil/wiki/Executable-Distributions

Note that the PM951 appears as /dev/nvme0n1 in Linux and /dev/sda is a secondary HDD.

Using secutil-cli

It seems secutil-cli is not able to talk to or detect the PM951 on /dev/nvme0n1.

Query fails to talk to it.

# I wasn't sure if 'query' wanted /dev/nvme0 or /dev/nvme0n1 so I tried both.
$ sudo ./sedutil-cli --query /dev/nvme0
NVME Security Command Error:8194
- 13:45:34.633 ERR : Invalid or unsupported disk /dev/nvme0

$ sudo ./sedutil-cli --query /dev/nvme0n1
NVME Security Command Error:8194
- 13:45:46.106 ERR : Invalid or unsupported disk /dev/nvme0n1

Scan fails to find it.

# Note that the PM951 is not found by 'scan'. Only the HDD on /dev/sda is found.
$ sudo ./sedutil-cli --scan

Scanning for Opal compliant disks
/dev/sda No  WDC WD10SPCX-24HWST1                     02.01A02
No more disks present ending scan

Testing the PBA

I tried testing the PBA with the instructions at https://github.com/Drive-Trust-Alliance/sedutil/wiki/Test-the-PBA

My system is configured to boot with UEFI and I turned off Secure Boot to be able to boot the PBA.

First, I installed the PBA to a USB drive with: sudo dd if=UEFI64_Release.img of=/dev/sdb

When booting to that USB drive, the first password prompt appears. After entering dummy text (I used "asdf"), it immediately reboots the entire machine which then proceeds boot into Ubuntu. The scan and second password prompt never appear (though it is possible they flash by to quickly for me to see.)

If during that reboot I have it boot to the USB drive again, the first password prompt again appears.

System Specs

Machine: Lenovo Y700 Touch-15ISK
Model: 80NW0017US

BIOS/UEFI version: CDCN35WW (I am booting in UEFI mode.)

OS: Ubuntu 16.04 (preview)
Output of uname -a:
Linux spiritus 4.4.0-18-generic #34-Ubuntu SMP Wed Apr 6 14:01:02 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
Kernel boot parameters: I added libata.allow_tpm=1 to the kernel parameters in Grub. Without that sedutil-cli exits with an error about libata.allow_tmp not being set to 1.

SSD (added by me):
Samsung PM951 512GB M.2 NGFF PCIe Gen3 x4, NVME Solid state drive SSD, OEM (2280) ( MZVLV512HCJH-00000)
Linux Device: /dev/nvme0n1
Output of lshw:

        *-pci:4
             description: PCI bridge
             product: Sunrise Point-H PCI Express Root Port #9
             vendor: Intel Corporation
             physical id: 1d
             bus info: pci@0000:00:1d.0
             version: f1
             width: 32 bits
             clock: 33MHz
             capabilities: pci pciexpress msi pm normal_decode bus_master cap_list
             configuration: driver=pcieport
             resources: irq:126 ioport:3000(size=4096) memory:94000000-940fffff
           *-storage
                description: Non-Volatile memory controller
                product: Samsung Electronics Co Ltd
                vendor: Samsung Electronics Co Ltd
                physical id: 0
                bus info: pci@0000:0a:00.0
                version: 01
                width: 64 bits
                clock: 33MHz
                capabilities: storage pm msi pciexpress msix nvm_express bus_master cap_list
                configuration: driver=nvme latency=0
                resources: irq:0 memory:94000000-94003fff ioport:3000(size=256)

It would be nice if PBA implemented a feature, where you set a second, special password, that upon its entry, the PBA would revertTper, and thus destroy the data residing on disk.

Encrypting your drive refers to Test the PBA as a recommended step. The UEFI PBA behaviour is not the same as the LinuxPBA, and as such differs from the documentation. Initially this caused me some alarm until recalling the project history. I do have the UEFI PBA working correctly, and the rescue image instructions (Test the rescue system) worked for my initial broken set up with the UEFI PBA.

In addition, would it be possible to document the login, and password for the UEFI debug build?

If during setup/install the user fails to enable any locking ranges but enables and loads a PBA sedutil will report that the drive is unlocked even though it is in fact only being unshadowed.

Hello, I followed the guide in this link: https://github.com/Drive-Trust-Alliance/sedutil/wiki/Test-the-PBA, I entered random digits to let Sedutil scan my drives, and this was the result: picture
Sorry for the blurred image, as the system reboots very fast after this message.
I succeed on checking my device for support, as I used the sedutil-cli.exe --query command.
Here is the result:

C:\Windows\system32>c:\temp\sedutil-cli.exe --query .\PhysicalDrive0

.\PhysicalDrive0 ATA Samsung SSD 850 EVO 250GB EMT02B6Q S21NNXCGA01047X
TPer function (0x0001)
ACKNAK = N, ASYNC = N. BufferManagement = N, comIDManagement = N, Streaming = Y, SYNC = Y
Locking function (0x0002)
Locked = N, LockingEnabled = N, LockingSupported = Y, MBRDone = N, MBREnabled = N, MediaEncrypt = Y
Geometry function (0x0003)
Align = N, Alignment Granularity = 1 (512), Logical Block size = 512, Lowest Aligned LBA = 0
Opal V1.0 function (0x0200)
Base comID = 0x1004, comIDs = 1
SingleUser function (0x0201)
ALL = N, ANY = N, Policy = Y, Locking Objects = 9
DataStore function (0x0202)
Max Tables = 9, Max Size Tables = 10485760, Table size alignment = 1
OPAL 2.0 function (0x0203)
Base comID = 0x1004, Initial PIN = 0x0 , Reverted PIN = 0x0 , comIDs = 1
Locking Admins = 4, Locking Users = 9, Range Crossing = N

TPer Properties:
MaxComPacketSize = 66048 MaxResponseComPacketSize = 66048
MaxPacketSize = 66028 MaxIndTokenSize = 65992 MaxPackets = 1
MaxSubpackets = 1 MaxMethods = 1 MaxAuthentications = 5
MaxSessions = 1 MaxTransactionLimit = 1 DefSessionTimeout = 0

Host Properties:
MaxComPacketSize = 2048 MaxResponseComPacketSize = 65536
MaxPacketSize = 2028 MaxIndTokenSize = 1992 MaxPackets = 1
MaxSubpackets = 1 MaxMethods = 1

Anything that i'm doing wrong? Or as the query command was successful i should ignore the Test PBA step?

I've installed LinuxPBA on my SSD, and after entering correct password it reboots, wasting time for POST screen.

Building release 1.12 on current Arch Linux is not working. I'm probably not doing something that is needed or doing something wrong but this was working as expected before.

I'm changing directory into linux/CLI/ and then doing 'make CONF=Release_x86_64 build'. I'm getting the following error(s):

../DtaDevLinuxNvme.cpp: In member function ‘virtual uint8_t DtaDevLinuxNvme::sendCmd(ATACOMMAND, uint8_t, uint16_t, void_, uint16_t)’:
../DtaDevLinuxNvme.cpp:68:27: error: aggregate ‘DtaDevLinuxNvme::sendCmd(ATACOMMAND, uint8_t, uint16_t, void_, uint16_t)::nvme_admin_cmd nvme_cmd’ has incomplete type and cannot be defined
struct nvme_admin_cmd nvme_cmd;
^
../DtaDevLinuxNvme.cpp:92:18: error: ‘NVME_IOCTL_ADMIN_CMD’ was not declared in this scope
err = ioctl(fd, NVME_IOCTL_ADMIN_CMD, &nvme_cmd);
^
../DtaDevLinuxNvme.cpp: In member function ‘virtual void DtaDevLinuxNvme::identify(OPAL_DiskInfo&)’:
../DtaDevLinuxNvme.cpp:112:24: error: aggregate ‘DtaDevLinuxNvme::identify(OPAL_DiskInfo&)::nvme_admin_cmd cmd’ has incomplete type and cannot be defined
struct nvme_admin_cmd cmd;
^
../DtaDevLinuxNvme.cpp:122:18: error: ‘NVME_IOCTL_ADMIN_CMD’ was not declared in this scope
err = ioctl(fd, NVME_IOCTL_ADMIN_CMD, &cmd);
^
nbproject/Makefile-Release_x86_64.mk:182: recipe for target 'build/Release_x86_64/GNU-Linux/_ext/5c0/DtaDevLinuxNvme.o' failed
make[2]: *** [build/Release_x86_64/GNU-Linux/_ext/5c0/DtaDevLinuxNvme.o] Error 1

starting with the linux-4.4 release, the linux/nvme.h header no longer exists. it's been renamed & stripped down to linux/nvme_ioctl.h. it seems like sedutil is using a bunch of constants that the kernel guys considered "not part of the ABI", so that'll need address too.

If you have multiple SEDs with different passwords (or locking ranges I assume) and want to unlock them all, you have to wait through a reboot for each one.

Also, if the PBA is on the default boot device and it becomes unlocked it means you have to select another locked drive with the PBA to boot from, if your boot selection menu isn't locked down.

Some workarounds for users to avoid the second problem:

• Enter the default boot device's password last in the sequence
• Add an option in GRUB to chain load the rescue image as a last resort (untested)

First off, thank you for continuing this project and making it freely available. I have an enhancement request.

Quite simply, my need is to determine if there are any SED drives present in a system or not. The --scan command always returns a value of 0 unless there is some sort of error. Right now I am reading the stdout from --scan and parsing the text to figure out if there is or is not an SED drive. I would be nice to have a switch named --countSEDs (or something similar) which returns the number of SEDs present, and the exit code would also be that number so that it can be easily interpreted from another script. #

there is an error when loadPBAimage,the following is my step:

PS C:\Users\admin\Desktop\TCG_Copy\sedutil-master_2\windows\CLI\x64\Debug> .\sedutil-cli.exe --initialSetup 12345678 .\PhysicalDrive0

• 14:29:07.000 INFO: takeOwnership complete
• 14:29:08.859 INFO: Locking SP Activate Complete
• 14:29:08.625 INFO: LockingRange0 disabled
• 14:29:09.328 INFO: LockingRange0 set to RW
• 14:29:10.031 INFO: MBRDone set on
• 14:29:10.734 INFO: MBRDone set on
• 14:29:11.437 INFO: MBREnable set on
• 14:29:11.437 INFO: Initial setup of TPer complete on .\PhysicalDrive0
  PS C:\Users\admin\Desktop\TCG_Copy\sedutil-master_2\windows\CLI\x64\Debug> .\sedutil-cli.exe --loadPBAimage 12345678 C:\Users\admin\Desktop\UEFI64_1\UEFI64_Release-1.12.img .\PhysicalDrive0
• 14:30:19.000 INFO: Writing PBA to .\PhysicalDrive0
  • [** ] 665600- 14:31:22.203 ERR : Command failed on send 4
• 14:31:22.203 ERR : Command failed on exec 4
  PS C:\Users\admin\Desktop\TCG_Copy\sedutil-master_2\windows\CLI\x64\Debug>

It can also be written in a few days ago, but appear the problem today.I don't know why.
Who encountered this problem???Please give directions. thank you.

My SSD disk is Samsung SSD 850 EVO on WIN 8.
.

This is more or less feature request if you think that might be helpful to someone.

Currently, if I swap my system drive with OPAL SSD (presumably I'm having only one SATA slot) then the obvious way to test sedutil-cli and install the PBA is by using the rescue image on the USB thumb drive.
Once tested the sedutil and the SSD, you should be able to write the BIOS/UEFI64 PBA on the SSD.

Currently I'm doing something like this:

diff --git images/buildrescue images/buildrescue
index 63c972e..4f6b0c4 100755
--- images/buildrescue
+++ images/buildrescue
@@ -4,6 +4,8 @@ set -x
 ## define releases for tools
 . conf
 PROGRAM=../../linux/CLI/dist/Release_i686/GNU-Linux/sedutil-cli
+BIOSPBA=../LINUXPBARelease/LINUXPBARelease-*
+UEFI64PBA=../UEFI64_Release/UEFI64_Release-*
 VERSIONINFO=`git describe --dirty`
 BUILDTYPE=Rescue
 BUILDIMG=${BUILDTYPE}-${VERSIONINFO}.img
@@ -18,7 +20,7 @@ sudo rm -rf ${BUILDTYPE} ; mkdir ${BUILDTYPE} ; cd ${BUILDTYPE}
      -f ${PROGRAM} \
   ] || { echo " prereqs are not available "; exit 1; }
 #
-dd if=/dev/zero of=${BUILDIMG} bs=1M count=15
+dd if=/dev/zero of=${BUILDIMG} bs=1M count=30
 (echo o;echo n;echo p;echo 1;echo "";echo "";echo a;echo 1;echo w) | fdisk -C 100 ${BUILDIMG}
 dd if=../scratch/${SYSLINUX}/bios/mbr/mbr.bin of=${BUILDIMG} count=1 conv=notrunc bs=512
 LOOPDEV=`sudo losetup --show -f -o 1048576 ${BUILDIMG}`
@@ -44,6 +46,21 @@ cd ..
 sudo mkdir -p core/usr/local/sbin/
 sudo unsquashfs -f -li -d core ../scratch/hdparm.tcz
 sudo cp ${PROGRAM} core/usr/local/sbin/
+
+if [ -e ${BIOSPBA} ]
+then
+    sudo mkdir -p core/usr/local/pba
+    zcat ${BIOSPBA} >./LINUXPBARelease.img
+    sudo cp ./LINUXPBARelease.img core/usr/local/pba/
+    rm -f ./LINUXPBARelease.img
+fi
+if [ -e ${UEFI64PBA} ]
+then
+    sudo mkdir -p core/usr/local/pba
+    zcat ${UEFI64PBA} >./UEFI64_Release.img
+    sudo cp ./UEFI64_Release.img core/usr/local/pba/
+    rm -f ./UEFI64_Release.img
+fi
 ## now repackage it
 cd core
 sudo find | sudo cpio -o -H newc | gzip -9 > ../image/boot/core.gz

I'm not quite happy with the implementation, but at least I'm guarding against missing images (not yet built).

Also, I'm not sure whether I can use the UEFI64 image to write it with sedutil-cli, since the rescue image boots in BIOS mode?

I'm trying to encrypt my system drive, a Samsung 850 EVO 500GB mSATA drive, on a NEC LaVie laptop. I have an existing Windows 8.1 installation I want to keep. The BIOS is UEFI, and Windows was installed in UEFI mode.

In Windows sedutil can see and set up the drive as per the instructions at https://github.com/Drive-Trust-Alliance/sedutil/wiki/Encrypting-your-drive

I tried the UEFI64 PBA on a USB drive and it doesn't seem to work. Messages flash up too fast to read after entering the first password. I tried the debug version and saw the following:

EER: method status code NOT_AUTHORISED
ERR: Season start failed
ERR: one or more header fields have 0 length
ERR: EndSession failed
EER: Unable to set LockingRange 0 RW
ERR: Identity failed Invalid argument

Scanning...

Unlocking /dev/sda Failed

However, since everything seems to be working in Windows (no error messages when locking the drive) I decided to backup and try it anyway. Once the PBA and MBR were installed the drive became unbootable. The UEFI BIOS would not see it as a bootable drive. I loaded up the rescue image, unlocked the drive and removed the MBR, and Windows was bootable again.The rescue image had to be run in legacy BIOS mode.

Question 1 - Is this output from the UEFI64 PBA telling me that it won't work, or merely that the drive is not encrypted so it can't do anything?

Question 2 - Why was Windows unbootable? Are those instructions incorrect for UEFI Windows installations?

Thanks for any assistance.

I have an Acer Inspire laptop and have replaced the original HDD with a Samsung 850 EVO. I am running Kubuntu 15.10 and have successfully installed sedutil, set up a BIOS-based PBA and generally got encryption working.

So far so good. However, when the laptop wakes up from suspend I get problems. Most executables stop working, the klog contains errors and the only way out is to reboot. After a reboot everything works fine again. I was wondering if the cause of this might be that suspend is totally powering down the drive, thus re-encrypting it so that on wake only the PBA would be available. Does this seem possible / likely? Is OPAL even supposed to work with suspend? And if it is supposed to work, are there certain power management settings I should look for to prevent the SSD being turned off during suspend?

Alternatively, is there a way of decrypting the drive again after the system wakes from suspend? I guess I would need to keep a copy of sedutil in a ramdisk but that's easy enough. Whether the system would accept that the "missing" SSD had returned to life would be another question, I guess.

Anyway, thanks for making such a useful tool.

Regards,

Adrian.

Repost of https://github.com/r0m30/msed/issues/48
The PBA image won't detect my drive.
I'm using a brand nes Samsung 850 Evo 250GB on a Dell Latitude E6500.

I am suck on testing PBA. In both BIOS1.12 and UEFI1.12 after entering pass errors show up http://imgur.com/a/AlOZ9 and computer restarts. Sorry for quality of pictures but it is visible only for fraction of a second.

Possibly helpful:

zba@zba-desktop:~/sedutil/Release_x86_64/GNU-Linux$ sudo ./sedutil-cli --scan
Scanning for Opal compliant disks
/dev/sda 2 Crucial_CT250MX200SSD1 MU01
/dev/sdb No ST3500320AS SD1A
/dev/sdc No
No more disks present ending scan

zba@zba-desktop:~/sedutil/Release_x86_64/GNU-Linux$ sudo ./sedutil-cli --query /dev/sda
/dev/sda ATA Crucial_CT250MX200SSD1 MU01 15040E8CCA9E
TPer function (0x0001)
ACKNAK = N, ASYNC = N. BufferManagement = N, comIDManagement = N, Streaming = Y, SYNC = Y
Locking function (0x0002)
Locked = N, LockingEnabled = Y, LockingSupported = Y, MBRDone = N, MBREnabled = N, MediaEncrypt = Y
Geometry function (0x0003)
Align = Y, Alignment Granularity = 8 (4096), Logical Block size = 512, Lowest Aligned LBA = 0
SingleUser function (0x0201)
ALL = Y, ANY = N, Policy = N, Locking Objects = 16
DataStore function (0x0202)
Max Tables = 16, Max Size Tables = 94371840, Table size alignment = 1
OPAL 2.0 function (0x0203)
Base comID = 0x1000, Initial PIN = 0x0, Reverted PIN = 0x0, comIDs = 1
Locking Admins = 4, Locking Users = 16, Range Crossing = N
TPer Properties:
MaxComPacketSize = 131072 MaxResponseComPacketSize = 131072
MaxPacketSize = 129792 MaxIndTokenSize = 126976 MaxPackets = 1
MaxSubpackets = 1 MaxMethods = 1 MaxSessions = 1
MaxAuthentications = 21 MaxTransactionLimit = 1 DefSessionTimeout = 240000
Host Properties:
MaxComPacketSize = 2048 MaxResponseComPacketSize = 2048
MaxPacketSize = 2028 MaxIndTokenSize = 1992 MaxPackets = 1
MaxSubpackets = 1 MaxMethods = 1

Hello!

What is the correct order of tests to be done? Do I need to test PBA first, or run --initialsetup first?
I thought it worth testing PBA first, but there is info (#37 (comment)) that this cannot be done before OPAL is enabled.

If testing PBA first I experience issue exactly to this: #44

I want to use a Micron M500 in my laptop which has 2 linux distros and Windows 10 home on it. LINUXPBA and biospba boot from a USB thumbdrive to request the password. I would like to boot to grub-2 on /dev/sda and from their choose the OS. Should I use the LINUXPBA, biospba or WindowsPBA?

On Windows 10, if I power up a locked non-OS drive before boot, PBA unlocks it properly.

If I power up AFTER boot, some MSED commands are required to make the drive available. These are the ones that seem to work:

setMBRDone on ...
setLockingRange 0 RW ...

I also have to issue a "diskpart" rescan command to properly mount the drive, else it shows up as uninitialized.

Is this the normal recommended sequence?

Also, is there anything in the MSED query results that tell me if ALL these things have been done; IOW, something that says that drive is ready to use and NOT still using a shadow partition?

Thanks.

It would be nice if linuxpba could also read the password from standard input and/or a file.

If this was possible then the pba image(1) could be made more flexible, as in allowing the storage of the password on a usb flash drive or other removable media.

If this support is implemented, an option (command line switch) not to reboot automatically could also be useful so it would be possible to fallback to keyboard input if the password provided by the file or standard input is not correct.

linuxpba would need to support only reading from standard input and/or a file and if possible support not rebooting automatically, all the logic to get the file, pass it to linuxpba and password input method fallback would be handled by a custom script.

(1) This could be a custom image made by each distribution to include other things, such as allowing the user to choose a keyboard layout or having the layout preset to the user's local layout.

Hi,
is there currently a method to achieve a configuration that will give me a master password ( as far as I understand it is Admin1 ) and a user password only to unlock the drive.
The master password could be used for example by the IT department to unlock the drive when user forgets its password.
The user should be not permitted to change the master password etc.
I've done:

sedutil-cli -–initialsetup
sedutil-cli –-loadPBAimage
sedutil-cli –-setMBREnable on
sedutil-cli –-enableLockingRange 0

and then

setSIDPwd

but the drive unlocks only when the Admin1 password is provided.
What is the purpose of SID password?

I would love to see you offer yubikey support. Its now almost the defacto standard for two factor auth hw especially among individual-small to medium size businesses.

I, personally, would be more than happy to donate to DTA a number of new yubikey 4 sticks so that you can use for development testing and your own use afterwards. Being a individual I am only able to do so much but IMO that is the least I could do to say thank you for the work. I also know for a fact this would drive many people into using this software.

I seem to see the request for new functions most activity is for sleep function and can not help but think SOME of thpeople that want this possibly do not understand the security ramifications or complexity of this from a PBA level or possibly may be rather willing (not need) this level of security and care more for the convenience at the cost of some security. TPM are not full proof and intel has already shown its willingness to break/weaken encryption (breaking the rng) We use TPMs only for confirming the sealed hw pcr from tampering, never actual crypt paraphrase key file storage. Hibernation on a current opal 2 ssd is what 15 sec to bring back up. Battery life is already 2x that of just a couple years ago and most savings can be gotten from scrn off and cpu power management when at rest settings.

But the one area of hibernation when using a properly formed and length paraphrase is its reentering. When tired or in a rush this can be a bit of a issue. Yubikey would tech allow a shorter password and still add considerably more security and even more so if password length is not cut. I personally would still keep a very strong phrase but others may then go to a short pin and still have higher security. But I think this would also help those wanting the sleep function as they could set a shorter pin and thus log in much quicker than say a 21 character covering all various ascii groups.

Yubikey has supplied all the packages other than the standard crypto libraries which are already out there. It seems adding its function to your current linux PBA image would not be too extensive. It would work in challenge and response mode and most would likely use slot 2 for this as slot 1 is already preconfig for OTP with there server auth. There certainly have been numerous github projects that offer this for luks and linux login

I already created a full use rescue usb that includes on board copies of the pba images to give a full feature rescue one stop shop. Thank you for helping with that. I will have to see how this new updated now named SEDUTILs looks as it was the last version of MSED I am presently running. See you have added uefi support very nice as it has good timing with Qubes full change over to multiboot soon as right not their uefi is not as fully supported as legacy bios mode.

So the offer stands I am willing to donate a number yubikey 4 sticks to help get yubikey support for SEDUTILs dev work and use by the devs.

Cheers,

Tim

Using the windows version, installed this on a Samsung 850 EVO HP15-t-100 E1P05AV laptop. It took a while to get it working right mostly due to miscues and Opal drive not recognized when cabled thru USB. Two other machines I own that are AMD boards would not recognize the OPAL function but were helpful to transfer drive data.
Any plans or suggested schemes to incorporate W7 sleep into the setup? Hibernate works when forcing the PBA to run at resume but hibernate is a SSD killer.
Thanks in advance. Kevin

I've built on my machine the UEFI64 image and used it as PBA on my SSD.

When I'm booting from it I get the following error:

can't run '/etc/init.d/rcS': No such file or directory

Apart from that I also get "/sbin/linuxpba: error while loading shared libraries" reported in the #21

After getting a root shell I have verified that the /etc/init.d/ is empty, so I have no idea where the "buildUEFI64" failed and why rcS is missing.

Do you have any ideas?

I'm getting "No bootable device" error after completing these steps in Windows 10:

sedutil-cli -–initialsetup <password> <drive>
sedutil-cli –-loadPBAimage <password> <pbafilename>  <drive>
sedutil-cli –-setMBREnable on <password> <drive>

Samsung 850 EVO SSD with Windows 10 x64 with UEFI

Fix was easy: boot with rescue, issue:
sedutil-cli --revertnoerase {Admin1Password} {drive}

My setup is as follows:
Asus latop with "Aptio Setup Utility" by "American Megatrends, Inc.", version 2.15.1236
On the SSD I have installed UEFI64 PBA.

When I start the machine for the first time, the SSD loads the UEFI64, then I enter the passwords and the machine is rebooted again which leads directly to the BIOS settings, instead of booting my Linux.

Upon inspection of the Boot settings I see that I have only one Boot option left:
"Windows Boot Manager (P4: Samsung SSD 850 PRO)", while the other option ("Antergos" arch linux) is gone! This "Windows Boot Manager" is quite misleading, since I don't really have Windows OS installed. Basically, the "Antergos" boot entry vanishes after the PBA authentication.

Previously, I have noticed that if I remove the hard drive, then upon BIOS boot, this particular EFI entry is automatically removed! Later if I reintroduce the removed disk, unfortunately the BIOS won't reinstate the removed Boot entry!

Originally, the way this entry is added, is by using "grub-install", which in return calls the efibootmgr. This is the same tools used by the OS setup process. The grub setup creates the following EFI entry:
/boot/efi/EFI/antergos/grubx64.efi

The OS install setup is more generous and it actually creates a couple more "alias" like:
/boot/efi/EFI/BOOT/BOOTX64.efi/grubx64.efi
and
/boot/efi/EFI/Microsoft/Boot/bootmgfw.efi

I didn't realize at first what is all this for, but now I guess this is just a "hack", depending of your (broken) UEFI BIOS implementation, so your BIOS can find and boot at least one of those efi-s.

All this works just fine, but only with regular SSD (without Opal SED enabled mode).

One explanation could be:
Once the machine is started, UEFI Bios boots the UEFI64 PBA, by reading EFI\boot\bootx64.efi
unfortunately after the reboot the PBA hard drive "disappear" and the "real" drive comes in to play. Since the PBA hard drive is "gone" and my BIOS likes to remove boot entries for the missing devices, that cause the BIOS to open the setup instead.

Now, to boot I have to go to the "Boot" tab and create manually a boot entry (you can browse for the .efi file on the detected partitions in my BIOS setup), Save and reboot again in order to boot the Linux at last.
Sadly, I have to do that every time I shutdown the PC (between reboots the BIOS doesn't forget the boot entry).

My first attempt to solve that problem was to create exactly the same path as you did for the UEFI64 PBA boot efi, i.e. to create on my linux: /boot/efi/EFI/boot/bootx64.efi in hope that path is somewhat magical to the BIOS, but I had no luck. The BIOS removes the boot entry immediately after the initial boot (from power off state). I guess the reason is that the hard drive "signature" is different (different size, count of partitions, UUID, or something else, between shadow and real ssd partitions).

Lucky for me I found the magic path for my BIOS and it was hinted by this "Windows Boot Manager" that always comes from thin air when I reboot after the PBA authentication.
What I did is actually to remove all directories from /boot/efi/EFI and keep just one .efi file under the path:
/boot/efi/EFI/Microsoft/Boot/bootmgfw.efi
For some reason it should be that file and then the BIOS will accept it as fallback (rationale: added support for Windows OS with UEFI).
This workaround should work, but it is (BIOS) implementation specific and I imagine this won't be universal solution. Besides grub creates .efi file by default under its own path and BIOS doesn't behave!

I guess tickets like this one will keep coming once the SED utility become better adopted. I.e. people with UEFI to not be able to boot their drive after the PBA authentication.

One suggestion might be to integrate the efibootmgr tool and use it with "boot" parameters, specified on the sedutil-cli --loadPBAimage line, after successful authentication.
So, the user should know the required arguments for the efibootmgr to create a boot entry. Once those arguments are stored inside the UEFI64 image and saved on the PBA partition then that information can be later used, before or after the user successfully enteres their password and thus the (re)boot process will succeed no matter how stupid the UEFI BIOS is.