Script / method to erase USB flash drive content after a certain number of uses

You want a DRM, not an "integrity" solution

First a small vocabulary precision. The "data integrity" term you use doesn't seem appropriate regarding your needs.

• A data integrity method would ensure that the data on the flash drive is genuine and/or cannot be in a corrupted or incoherent state, but this do not seem to be your concern here.
• A Digital Right Management (DRM) method, according to Wikipedia, "is a term referring to various access control technologies that are used to restrict the usage of proprietary software, hardware, or content.

So what you need is a DRM solution, and not a data integrity solution.

Possible, but only on an industrial or semi-industrial scale

There is no really viable protection relying solely on the OS or any data publicly stored on the thumb-drive. Indeed, it is trivial to dump the raw thumb-drive content and restore it later to put it back in its pristine state.

So, you can forget about self-deleting content, standard encryption which will be of no help against this, do not even think about storing a counter in some unallocated zone of the file-system (such tricks were used to protect CD-ROM's in the late 90's but will be of no help here).

Some other answers suggest the use of an Internet-based service. This is how DRM-enabled PDF documents work: the document themselves are encrypted and upon each opening the decryption key is requested to some Adobe server. This may work, but you have better ensure that your software requesting the key and the protocol it uses cannot be reversed or replayed, otherwise the end-user will be able to get around your protection. All security will rely on this, and given enough time and determination consider that your software will eventually be broken, it just a matter of profit vs. efforts needed.

The solution I suggest doesn't require any Internet access from the end-user and gives a good protection against reverse engineering attempts by keeping the security system out of the reach of end-users.

A firmware-based solution

You will need something not reachable to the user, and this will most probably mean you will have to customize your own firmware for the job.

Following my idea, the storage area of your flash drive should be divided in three zones:

• One public and relatively small zones containing just enough material to initiate the boot procedure (it needs to be accessible to a standard BIOS),
• One very tiny zone accessible only to the firmware (and never accessible to the computer) storing the counter and, possibly, some other configuration and/or authentication material,
• The largest zone, accessible to the computer only after a successful internal authentication.

The boot process would go as follow:

1. The BIOS read the publicly accessible boot sector and initial boot executable,
2. This initial executable initiates some custom authentication procedure with your firmware to unlock access to the main data,
3. If the authentication is successful and the maximum number of allowed unlocks not reached yet, the firmware increments its internal unlock counter (stored in his private area) and then effectively unlock the main storage area,
4. Once the main storage is accessible, the boot process can continue as usual.

Potential weaknesses

First potential weaknesses I could see:

• I do not know which application you intend to run on such thumb-drive, however an end-user may try to extract and copy the unlocked content (whether directly from the USB drive or from the mounted RAM disk) if your software allows him to do so (for instance if he is allowed to open a shell with root access). So you may want to restrict the user's privileges on the running system to prevent this.
• Your initial boot executable may use some obfuscation technique to prevent the authentication procedure to be easily leaked. In the hands of determined attacker, expect dead and live analysis since they can for instance connect your thumb-drive to a virtual machine to simulate a boot process and analyze the exchange between the initial executable and the thumb-drive. The good news is that, even if the authentication process and secrets are reversed, this will not allow to tamper with the unlock counter or unlock an already locked thumb-drive.
• Your firmware may be overwriteable. When selecting a provider for your chips, you must ensure that they offer the possibility to lock any further update or rewrite of your firmware code. This may not be obvious, but there is actually plenty of USB devices where the firmware can be rewritten by end-users, see BadUSB. Since your security relies on your firmware, this may be an important criteria for you.
• If the value is high enough, a determined attacker may be willing to access directly the data stored in the NAND storage chips inside the thumb-drive. If this is a concern for you, you may want to implement on-the-fly encryption in your firmware so all stored data will be systematically encrypted.

Feasibility / credibility

• Custom flash drive: A quick search let me find several open sourced USB keys with customizable firmware already available in retail and wholesale, however they were targeting the more profitable market of security tokens which mean they add a more costly cryptographic hardware to the key. Most chances are that cheaper already-made USB keys can be found at lower price.

• Custom firmware: Creating his own firmware may sound highly technical, but I do not think it really is. USB chips provider also provide the associated development framework which include libraries acting as an abstraction level over USB low-level operations and placeholders for the user's customized code. As a sample here is a random documentation for such a library so you can get yourself an idea. The main prerequisites are to know how to write C applications, how to use an IDE, and have only a basic understanding of how USB works.

• Divide the storage area and control access to each zone: This is not my invention, as far as I remember this is how the DRM extension for SD cards is implemented. To learn more on this topic, this specification is confidential however some part of it (at least) leaked on the Internet despite the non-disclosure agreements. I am not reinventing the wheel.

• On-the-fly encryption: There are already USB token providing on-the-fly encryption, however to achieve good performance they bundle some cryptographic hardware. Since encryption is not your first goal here, and if you really need to encrypt the storage area (ie. if you fear that your users will take your flash disks apart and access the raw NAND chips content directly), you may still be able to do without such hardware but you will have to restrain yourself to very low resources algorithms. In fact, with a flash drive limited computing resources, you may go more toward some data obfuscation scheme than a true highly secure encryption algorithm.

Maybe you're falling into the XY problem trap here. Are you sure the answer lies in how the USB self-destructs as opposed to taking some standard licensing measures? i.e. if you can confidently say the OS will rely on an internet connection - you can quite easily block it after the first use.

If, in fact, what you're actually asking is how you'd protect what's actually on the disk (i.e. the files mustn't be accessed) - they really, really shouldn't be on a USB drive you plan on distributing in the first place. To want people to read the file contents, but only once is impossible without a particular level of control over their machine.

If your booting system is going to have access to the Internet or an intranet you can positively control the process by completing the install with a network install initiated by the USB drive.

You would be doing a hybrid PXE boot install with the USB actually initiating the boot and first level install. Consider installing a minimally functional OS with the USB install and then pulling the real OS image from the network as an ISO file. If you need this instance to only run once you then move the network image to RAM and mount loopback.

The control of the number of uses would be delegated to the network server that passes back the ISO installation image.

This scheme also can be made to address the cases where the installation is aborted midsteam or one of the many things that can go wrong does. A one shot and your done plan needs a Plan B if there are many installations planned and this scheme could allow approving a second try without sending another USB.