Should a secure ATA erase be performed on a non-SSD drive?
When running the command hdparm -I /dev/sda
the following output is generated.
ATA device, with non-removable media
Model Number: WDC WD10JPVX-75JC3T0
Serial Number: WX51A9324970
Firmware Revision: 01.01A01
Transport: Serial, SATA 1.0a, SATA II Extensions, SATA Rev 2.5, SATA Rev 2.6, SATA Rev 3.0
Standards:
Supported: 9 8 7 6 5
Likely used: 9
Configuration:
Logical max current
cylinders 16383 16383
heads 16 16
sectors/track 63 63
--
CHS current addressable sectors: 16514064
LBA user addressable sectors: 268435455
LBA48 user addressable sectors: 1953525168
Logical Sector size: 512 bytes
Physical Sector size: 4096 bytes
Logical Sector-0 offset: 0 bytes
device size with M = 1024*1024: 953869 MBytes
device size with M = 1000*1000: 1000204 MBytes (1000 GB)
cache/buffer size = 8192 KBytes
**Nominal Media Rotation Rate: 5400**
Of interest is the description and value Nominal Media Rotation Rate: 5400
. This indicates that the hard drive is mechanical and not flash.
There is support for ATA secure erase as suggested by the output albeit I would have not anticipated a secure erase taking as long as 198 mins.
Security:
Master password revision code = 65534
supported
not enabled
not locked
not frozen
not expired: security count
supported: enhanced erase
198min for SECURITY ERASE UNIT. 198min for ENHANCED SECURITY ERASE UNIT.
Given that the device is not a solid state drive, should a secure ATA erase still be performed?
If no, why? If yes, why?
Would shred --verbose --random-source=/dev/urandom -n1 /dev/sda
support the same or a similar outcome i.e. irrecoverable data including defective or deallocated sectors?
deletion destruction data-remanence
add a comment |
When running the command hdparm -I /dev/sda
the following output is generated.
ATA device, with non-removable media
Model Number: WDC WD10JPVX-75JC3T0
Serial Number: WX51A9324970
Firmware Revision: 01.01A01
Transport: Serial, SATA 1.0a, SATA II Extensions, SATA Rev 2.5, SATA Rev 2.6, SATA Rev 3.0
Standards:
Supported: 9 8 7 6 5
Likely used: 9
Configuration:
Logical max current
cylinders 16383 16383
heads 16 16
sectors/track 63 63
--
CHS current addressable sectors: 16514064
LBA user addressable sectors: 268435455
LBA48 user addressable sectors: 1953525168
Logical Sector size: 512 bytes
Physical Sector size: 4096 bytes
Logical Sector-0 offset: 0 bytes
device size with M = 1024*1024: 953869 MBytes
device size with M = 1000*1000: 1000204 MBytes (1000 GB)
cache/buffer size = 8192 KBytes
**Nominal Media Rotation Rate: 5400**
Of interest is the description and value Nominal Media Rotation Rate: 5400
. This indicates that the hard drive is mechanical and not flash.
There is support for ATA secure erase as suggested by the output albeit I would have not anticipated a secure erase taking as long as 198 mins.
Security:
Master password revision code = 65534
supported
not enabled
not locked
not frozen
not expired: security count
supported: enhanced erase
198min for SECURITY ERASE UNIT. 198min for ENHANCED SECURITY ERASE UNIT.
Given that the device is not a solid state drive, should a secure ATA erase still be performed?
If no, why? If yes, why?
Would shred --verbose --random-source=/dev/urandom -n1 /dev/sda
support the same or a similar outcome i.e. irrecoverable data including defective or deallocated sectors?
deletion destruction data-remanence
add a comment |
When running the command hdparm -I /dev/sda
the following output is generated.
ATA device, with non-removable media
Model Number: WDC WD10JPVX-75JC3T0
Serial Number: WX51A9324970
Firmware Revision: 01.01A01
Transport: Serial, SATA 1.0a, SATA II Extensions, SATA Rev 2.5, SATA Rev 2.6, SATA Rev 3.0
Standards:
Supported: 9 8 7 6 5
Likely used: 9
Configuration:
Logical max current
cylinders 16383 16383
heads 16 16
sectors/track 63 63
--
CHS current addressable sectors: 16514064
LBA user addressable sectors: 268435455
LBA48 user addressable sectors: 1953525168
Logical Sector size: 512 bytes
Physical Sector size: 4096 bytes
Logical Sector-0 offset: 0 bytes
device size with M = 1024*1024: 953869 MBytes
device size with M = 1000*1000: 1000204 MBytes (1000 GB)
cache/buffer size = 8192 KBytes
**Nominal Media Rotation Rate: 5400**
Of interest is the description and value Nominal Media Rotation Rate: 5400
. This indicates that the hard drive is mechanical and not flash.
There is support for ATA secure erase as suggested by the output albeit I would have not anticipated a secure erase taking as long as 198 mins.
Security:
Master password revision code = 65534
supported
not enabled
not locked
not frozen
not expired: security count
supported: enhanced erase
198min for SECURITY ERASE UNIT. 198min for ENHANCED SECURITY ERASE UNIT.
Given that the device is not a solid state drive, should a secure ATA erase still be performed?
If no, why? If yes, why?
Would shred --verbose --random-source=/dev/urandom -n1 /dev/sda
support the same or a similar outcome i.e. irrecoverable data including defective or deallocated sectors?
deletion destruction data-remanence
When running the command hdparm -I /dev/sda
the following output is generated.
ATA device, with non-removable media
Model Number: WDC WD10JPVX-75JC3T0
Serial Number: WX51A9324970
Firmware Revision: 01.01A01
Transport: Serial, SATA 1.0a, SATA II Extensions, SATA Rev 2.5, SATA Rev 2.6, SATA Rev 3.0
Standards:
Supported: 9 8 7 6 5
Likely used: 9
Configuration:
Logical max current
cylinders 16383 16383
heads 16 16
sectors/track 63 63
--
CHS current addressable sectors: 16514064
LBA user addressable sectors: 268435455
LBA48 user addressable sectors: 1953525168
Logical Sector size: 512 bytes
Physical Sector size: 4096 bytes
Logical Sector-0 offset: 0 bytes
device size with M = 1024*1024: 953869 MBytes
device size with M = 1000*1000: 1000204 MBytes (1000 GB)
cache/buffer size = 8192 KBytes
**Nominal Media Rotation Rate: 5400**
Of interest is the description and value Nominal Media Rotation Rate: 5400
. This indicates that the hard drive is mechanical and not flash.
There is support for ATA secure erase as suggested by the output albeit I would have not anticipated a secure erase taking as long as 198 mins.
Security:
Master password revision code = 65534
supported
not enabled
not locked
not frozen
not expired: security count
supported: enhanced erase
198min for SECURITY ERASE UNIT. 198min for ENHANCED SECURITY ERASE UNIT.
Given that the device is not a solid state drive, should a secure ATA erase still be performed?
If no, why? If yes, why?
Would shred --verbose --random-source=/dev/urandom -n1 /dev/sda
support the same or a similar outcome i.e. irrecoverable data including defective or deallocated sectors?
deletion destruction data-remanence
deletion destruction data-remanence
edited Dec 25 '18 at 3:52
forest
35.4k17117123
35.4k17117123
asked Dec 25 '18 at 2:41
MotivatedMotivated
532412
532412
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
Given that the device is not a solid state drive, should a secure ATA erase still be performed?
If you want to erase the data, you can use ATA Secure Erase. It is not meant only for solid state drives and works fine on spinning rust. It takes a lot longer than on SSDs because hard drives are less likely to support SED, which allows instant erasure by destroying an encryption key.
Whether or not you use the firmware's secure erasure or erase the block device is something that is up to you. Both options come with advantages and disadvantages. For example, ATA Secure Erase is designed to erase areas of the drive that may not be touched by writing to the block device, such as damaged sectors and the HPA (Host Protected Area). On the other hand, any erasure implemented in firmware may be broken or implemented incorrectly, as you have no ability to easily tell how it is performing erasure. If you have time, you can perform both methods to get the best of both.
Would
shred --verbose --random-source=/dev/urandom -n1 /dev/sda
support the same or a similar outcome i.e. irrecoverable data including defective or deallocated sectors?
No, that would not erase damaged sectors, nor would it erase areas of the disk like the HPA. Note that the command you gave is functionally equivalent to cat /dev/urandom > /dev/sda
. You can, however, use smartmontools to determine how many damaged sectors your drive is reporting. If the value is zero, then every accessible sector can be wiped just by writing to the block device.
If you want to overwrite the block device, you can do so with dd
:
dd if=/dev/urandom of=/dev/sda bs=256k conv=fsync
This will write random data to the block device, and will sync the changes as soon as it has completed. On older Linux kernels, the random driver is very slow, in which case you should use other sources of randomness, for example creating an encrypted device with cryptsetup
and writing zeros to it.
In the future, there is a technique you should utilize to ensure you are not put into this position again. You should use full disk encryption with something like LUKS, which keeps the randomly-generated master password on the drive, encrypted with a user password you specify. Simply overwriting the encrypted master password is sufficient to render all other data on the drive completely irrecoverable. This works for hard drives where there is no wear leveling in place. On solid state drives, this will not work.
3
Comments are not for extended discussion; this conversation has been moved to chat.
– Rory Alsop♦
Dec 26 '18 at 11:59
@forest - Can you elaborate on the use ofcryptsetup
and writing zeros to it?
– Motivated
Jan 16 at 6:04
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "162"
};
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
},
noCode: 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%2fsecurity.stackexchange.com%2fquestions%2f200332%2fshould-a-secure-ata-erase-be-performed-on-a-non-ssd-drive%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
Given that the device is not a solid state drive, should a secure ATA erase still be performed?
If you want to erase the data, you can use ATA Secure Erase. It is not meant only for solid state drives and works fine on spinning rust. It takes a lot longer than on SSDs because hard drives are less likely to support SED, which allows instant erasure by destroying an encryption key.
Whether or not you use the firmware's secure erasure or erase the block device is something that is up to you. Both options come with advantages and disadvantages. For example, ATA Secure Erase is designed to erase areas of the drive that may not be touched by writing to the block device, such as damaged sectors and the HPA (Host Protected Area). On the other hand, any erasure implemented in firmware may be broken or implemented incorrectly, as you have no ability to easily tell how it is performing erasure. If you have time, you can perform both methods to get the best of both.
Would
shred --verbose --random-source=/dev/urandom -n1 /dev/sda
support the same or a similar outcome i.e. irrecoverable data including defective or deallocated sectors?
No, that would not erase damaged sectors, nor would it erase areas of the disk like the HPA. Note that the command you gave is functionally equivalent to cat /dev/urandom > /dev/sda
. You can, however, use smartmontools to determine how many damaged sectors your drive is reporting. If the value is zero, then every accessible sector can be wiped just by writing to the block device.
If you want to overwrite the block device, you can do so with dd
:
dd if=/dev/urandom of=/dev/sda bs=256k conv=fsync
This will write random data to the block device, and will sync the changes as soon as it has completed. On older Linux kernels, the random driver is very slow, in which case you should use other sources of randomness, for example creating an encrypted device with cryptsetup
and writing zeros to it.
In the future, there is a technique you should utilize to ensure you are not put into this position again. You should use full disk encryption with something like LUKS, which keeps the randomly-generated master password on the drive, encrypted with a user password you specify. Simply overwriting the encrypted master password is sufficient to render all other data on the drive completely irrecoverable. This works for hard drives where there is no wear leveling in place. On solid state drives, this will not work.
3
Comments are not for extended discussion; this conversation has been moved to chat.
– Rory Alsop♦
Dec 26 '18 at 11:59
@forest - Can you elaborate on the use ofcryptsetup
and writing zeros to it?
– Motivated
Jan 16 at 6:04
add a comment |
Given that the device is not a solid state drive, should a secure ATA erase still be performed?
If you want to erase the data, you can use ATA Secure Erase. It is not meant only for solid state drives and works fine on spinning rust. It takes a lot longer than on SSDs because hard drives are less likely to support SED, which allows instant erasure by destroying an encryption key.
Whether or not you use the firmware's secure erasure or erase the block device is something that is up to you. Both options come with advantages and disadvantages. For example, ATA Secure Erase is designed to erase areas of the drive that may not be touched by writing to the block device, such as damaged sectors and the HPA (Host Protected Area). On the other hand, any erasure implemented in firmware may be broken or implemented incorrectly, as you have no ability to easily tell how it is performing erasure. If you have time, you can perform both methods to get the best of both.
Would
shred --verbose --random-source=/dev/urandom -n1 /dev/sda
support the same or a similar outcome i.e. irrecoverable data including defective or deallocated sectors?
No, that would not erase damaged sectors, nor would it erase areas of the disk like the HPA. Note that the command you gave is functionally equivalent to cat /dev/urandom > /dev/sda
. You can, however, use smartmontools to determine how many damaged sectors your drive is reporting. If the value is zero, then every accessible sector can be wiped just by writing to the block device.
If you want to overwrite the block device, you can do so with dd
:
dd if=/dev/urandom of=/dev/sda bs=256k conv=fsync
This will write random data to the block device, and will sync the changes as soon as it has completed. On older Linux kernels, the random driver is very slow, in which case you should use other sources of randomness, for example creating an encrypted device with cryptsetup
and writing zeros to it.
In the future, there is a technique you should utilize to ensure you are not put into this position again. You should use full disk encryption with something like LUKS, which keeps the randomly-generated master password on the drive, encrypted with a user password you specify. Simply overwriting the encrypted master password is sufficient to render all other data on the drive completely irrecoverable. This works for hard drives where there is no wear leveling in place. On solid state drives, this will not work.
3
Comments are not for extended discussion; this conversation has been moved to chat.
– Rory Alsop♦
Dec 26 '18 at 11:59
@forest - Can you elaborate on the use ofcryptsetup
and writing zeros to it?
– Motivated
Jan 16 at 6:04
add a comment |
Given that the device is not a solid state drive, should a secure ATA erase still be performed?
If you want to erase the data, you can use ATA Secure Erase. It is not meant only for solid state drives and works fine on spinning rust. It takes a lot longer than on SSDs because hard drives are less likely to support SED, which allows instant erasure by destroying an encryption key.
Whether or not you use the firmware's secure erasure or erase the block device is something that is up to you. Both options come with advantages and disadvantages. For example, ATA Secure Erase is designed to erase areas of the drive that may not be touched by writing to the block device, such as damaged sectors and the HPA (Host Protected Area). On the other hand, any erasure implemented in firmware may be broken or implemented incorrectly, as you have no ability to easily tell how it is performing erasure. If you have time, you can perform both methods to get the best of both.
Would
shred --verbose --random-source=/dev/urandom -n1 /dev/sda
support the same or a similar outcome i.e. irrecoverable data including defective or deallocated sectors?
No, that would not erase damaged sectors, nor would it erase areas of the disk like the HPA. Note that the command you gave is functionally equivalent to cat /dev/urandom > /dev/sda
. You can, however, use smartmontools to determine how many damaged sectors your drive is reporting. If the value is zero, then every accessible sector can be wiped just by writing to the block device.
If you want to overwrite the block device, you can do so with dd
:
dd if=/dev/urandom of=/dev/sda bs=256k conv=fsync
This will write random data to the block device, and will sync the changes as soon as it has completed. On older Linux kernels, the random driver is very slow, in which case you should use other sources of randomness, for example creating an encrypted device with cryptsetup
and writing zeros to it.
In the future, there is a technique you should utilize to ensure you are not put into this position again. You should use full disk encryption with something like LUKS, which keeps the randomly-generated master password on the drive, encrypted with a user password you specify. Simply overwriting the encrypted master password is sufficient to render all other data on the drive completely irrecoverable. This works for hard drives where there is no wear leveling in place. On solid state drives, this will not work.
Given that the device is not a solid state drive, should a secure ATA erase still be performed?
If you want to erase the data, you can use ATA Secure Erase. It is not meant only for solid state drives and works fine on spinning rust. It takes a lot longer than on SSDs because hard drives are less likely to support SED, which allows instant erasure by destroying an encryption key.
Whether or not you use the firmware's secure erasure or erase the block device is something that is up to you. Both options come with advantages and disadvantages. For example, ATA Secure Erase is designed to erase areas of the drive that may not be touched by writing to the block device, such as damaged sectors and the HPA (Host Protected Area). On the other hand, any erasure implemented in firmware may be broken or implemented incorrectly, as you have no ability to easily tell how it is performing erasure. If you have time, you can perform both methods to get the best of both.
Would
shred --verbose --random-source=/dev/urandom -n1 /dev/sda
support the same or a similar outcome i.e. irrecoverable data including defective or deallocated sectors?
No, that would not erase damaged sectors, nor would it erase areas of the disk like the HPA. Note that the command you gave is functionally equivalent to cat /dev/urandom > /dev/sda
. You can, however, use smartmontools to determine how many damaged sectors your drive is reporting. If the value is zero, then every accessible sector can be wiped just by writing to the block device.
If you want to overwrite the block device, you can do so with dd
:
dd if=/dev/urandom of=/dev/sda bs=256k conv=fsync
This will write random data to the block device, and will sync the changes as soon as it has completed. On older Linux kernels, the random driver is very slow, in which case you should use other sources of randomness, for example creating an encrypted device with cryptsetup
and writing zeros to it.
In the future, there is a technique you should utilize to ensure you are not put into this position again. You should use full disk encryption with something like LUKS, which keeps the randomly-generated master password on the drive, encrypted with a user password you specify. Simply overwriting the encrypted master password is sufficient to render all other data on the drive completely irrecoverable. This works for hard drives where there is no wear leveling in place. On solid state drives, this will not work.
edited Dec 25 '18 at 4:33
answered Dec 25 '18 at 3:50
forestforest
35.4k17117123
35.4k17117123
3
Comments are not for extended discussion; this conversation has been moved to chat.
– Rory Alsop♦
Dec 26 '18 at 11:59
@forest - Can you elaborate on the use ofcryptsetup
and writing zeros to it?
– Motivated
Jan 16 at 6:04
add a comment |
3
Comments are not for extended discussion; this conversation has been moved to chat.
– Rory Alsop♦
Dec 26 '18 at 11:59
@forest - Can you elaborate on the use ofcryptsetup
and writing zeros to it?
– Motivated
Jan 16 at 6:04
3
3
Comments are not for extended discussion; this conversation has been moved to chat.
– Rory Alsop♦
Dec 26 '18 at 11:59
Comments are not for extended discussion; this conversation has been moved to chat.
– Rory Alsop♦
Dec 26 '18 at 11:59
@forest - Can you elaborate on the use of
cryptsetup
and writing zeros to it?– Motivated
Jan 16 at 6:04
@forest - Can you elaborate on the use of
cryptsetup
and writing zeros to it?– Motivated
Jan 16 at 6:04
add a comment |
Thanks for contributing an answer to Information Security 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%2fsecurity.stackexchange.com%2fquestions%2f200332%2fshould-a-secure-ata-erase-be-performed-on-a-non-ssd-drive%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