I've got a feeling the answer to this is there is no way, but I'll give it a try anyway.
I have a SSD from a company laptop where the SATA controller failed. The SSD is encrypted using bitlocker and, naturally, there is some critical data on the drive and no backup. The recovery key is also missing. The drive is normally opened with a PIN and the TPM in the laptop.
Is there any way to use the TPM from the laptop with the failed controller to open the drive?
I think that without the recovery key, we're out of luck, but if anyone knows a way around this, I'd appreciate the help.
Are you able to get a copy off the encrypted data of the SSD, e.g. an image?
You could try booting the laptop with Windows, and see if the system picks up when mounting the image.
As far as I know, how BDE interacts with the TPM is not publicly known.
But if you could find out, libbde (http//code.google.com/p/libbde/) could be altered to deal with that.
If it is just the SATA controller that is dead, can you remove the drive from the laptop, place it into an external USB enclosure and boot from USB (on the same machine with the same TPM)?
Needless to say, I have never tried this & have no real idea if it would work.
Is this standalone implementation of BitLocker, or enterprise version?
If enterprise and it was set up correctly, the key is in the AD, and you can even make a VHD, and boot it with the key, TPM or not.
It is enterprise, but since we can't find the recovery key in the AD, I assume it's not set up correctly.
For the method you describe, what "key" do we need? Can you provide a link to instructions on how to use this method?
Having no recovery protectors (key or numeric password), there is no cheaper way than to replace the SATA controller.
Having no recovery protectors (key or numeric password), there is no cheaper way than to replace the SATA controller.
This is a laptop, so that would have to be a PCMCIA SATA card. I'm not sure if the BIOS could handle booting off that, but it is worth a try. Now, we just have to get the original laptop back from the hardware depot… roll
It is enterprise, but since we can't find the recovery key in the AD, I assume it's not set up correctly.
For the method you describe, what "key" do we need? Can you provide a link to instructions on how to use this method?
The information is in ms-FVE-RecoveryInformation under the machine object. If you have the machine name you can find this object. The RecoveryPassword contains the string that when a drive or VHD is slaved, is asked for.
This is a laptop, so that would have to be a PCMCIA SATA card. I'm not sure if the BIOS could handle booting off that, but it is worth a try.
That probably won't work. I meant on-board replacement and a prayer to pass the trusted-boot integrity check afterwards.
You could try JTAG or worst case chip off reading…
You could try JTAG or worst case chip off reading…
Completely irrelevant, the data is accessible on the drive, the issue is that the data on the drive is not in a readable format, eg it's ENCRYPTED.
Completely irrelevant, the data is accessible on the drive, the issue is that the data on the drive is not in a readable format, eg it's ENCRYPTED.
As a matter of fact the JTAG or direct chip reading jhup mentioned is NOT necessarily aimed to the chip(s) on the disk…. roll
jaclaz
Completely irrelevant, the data is accessible on the drive, the issue is that the data on the drive is not in a readable format, eg it's ENCRYPTED.
As a matter of fact the JTAG or direct chip reading jhup mentioned is NOT necessarily aimed to the chip(s) on the disk…. roll
jaclaz
Then would you like to clarify what it is aimed at?
Then would you like to clarify what it is aimed at?
The encryption is "linked" to some hardware (now failed) on the actual computer.
Some information is stored in one (or more) chip(s) on the physical laptop.
The general idea is
- find a replacement hardware (motherboard) identical to the failed one
- "transplant" either "physically" i.e. by desoldering and re-soldering the relevant chip(s) or "logically" by reading the contents of the chip(s) on the failed motherboard and writing these contents to the chip(s) on the working one
[/listo]
If you prefer, it is a matter of perfectly "cloning" the failed hardware.
jaclaz
I am only speaking about my own experience - I have had third party recover BitLockered SSD through JTAG.
It was an enterprise implementation, so we recovered the key from the AD, irrelevant of TPM.
Once an image of the SSD was recreated, a MS VHD was crafted and mounted. BitLocker asked for the key and all was beautiful.
The solution I am describing removes the hardware issue - I understand the loss of the key/TPM, and the hope in my previous post was that it is a proper corporate implementation. That would create a backup of the recovery key in the AD.
In my opinion, if imaging, even using JTAG or chip-off is feasible, it is simpler than attempting to find a replacement hardware. I believe this because finding a matching hardware is much more cumbersome and technically complicated than using JTAG/chip-off solutions.
When I had replaced controllers in drives, even revision numbers were significant. I admit I have only done about half dozen this way. The delay, cost of the hardware, finding out that there are other issues besides the PCB made it too expensive for me.
What is the risk and success rate of using a JTAG clip, reading the data, and reconstructing it into an image?
What is the risk and success rate of finding the controller, then attempting to recover the data through original ports?
I am also wondering, my JTAG solution would not work if the PCB is damaged in an SSD. I have seen SSDs where the control card and the memory storage are on a single board (I also seen daughter board configuration). If that is the case, and the board is damaged, what are the changes of "swapping" anything? That leaves chip-off as the only solution.
If you prefer, it is a matter of perfectly "imaging" the failed hardware. mrgreen
Again, your mileage may vary.