Should a secure ATA erase be performed on a non-SSD drive?












9















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?










share|improve this question





























    9















    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?










    share|improve this question



























      9












      9








      9


      2






      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?










      share|improve this question
















      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






      share|improve this question















      share|improve this question













      share|improve this question




      share|improve this question








      edited Dec 25 '18 at 3:52









      forest

      35.4k17117123




      35.4k17117123










      asked Dec 25 '18 at 2:41









      MotivatedMotivated

      532412




      532412






















          1 Answer
          1






          active

          oldest

          votes


















          10















          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.






          share|improve this answer





















          • 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 of cryptsetup and writing zeros to it?

            – Motivated
            Jan 16 at 6:04











          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
          });


          }
          });














          draft saved

          draft discarded


















          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









          10















          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.






          share|improve this answer





















          • 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 of cryptsetup and writing zeros to it?

            – Motivated
            Jan 16 at 6:04
















          10















          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.






          share|improve this answer





















          • 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 of cryptsetup and writing zeros to it?

            – Motivated
            Jan 16 at 6:04














          10












          10








          10








          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.






          share|improve this answer
















          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.







          share|improve this answer














          share|improve this answer



          share|improve this answer








          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 of cryptsetup and writing zeros to it?

            – Motivated
            Jan 16 at 6:04














          • 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 of cryptsetup 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


















          draft saved

          draft discarded




















































          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.




          draft saved


          draft discarded














          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





















































          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







          Popular posts from this blog

          Bressuire

          Cabo Verde

          Gyllenstierna