media file copy protection scheme, will it work?

[ggnfs000]

I thought about certain media file protection, not like super absolute protection but make it much harder than simple file copy and paste. I posted this in another forum, and thought post it here too.
For the sake of sanity, lets not discuss about ethicality and controversy around it. Just assume it is decided we will be using copy protection.
Since anything can be broken by brute force or simply reverse engineering the program itself, that is not considered here.
What I mostly interested is the protocol/scheme planned here can be breached.

Here is the idea:
Standard format such as jpg mpg mov will not work. Period.

Design proprietary format and application for it. That will be a huge amount of work. So middle ground is altered standard format such that it is no readable by standard a application. Therefore come up altered application that reads the media.

The way it works is application read a file and check the disk medium characteristic i.e. sha(serial no + number of blocks).

Ok here is the plan I came up with, will it work?

Message aka plain text=(Storage medium serial No + No. of blocks on the storage medium + some password + media file binary + some other optional artifacts etc.,)

1.
When creating media content:
Hash(plain text) = message digest.
Enc(Hash(plain text) = signature (encrypt with private key).

2.
Store private key on cold storage, do not ever lose it.
For every legitimate copies, re-generate private keys from seed.

3.
When playing media content:
Dec(signature) => generates Hash1 (decrypt with public key) - always generates same hash value.
Rehash(plain text) => generates Hash2 - if copied to different medium, file is corrupted or damaged, will generate different hash value. If file residing on original legitimate storage, will generate same hash.

If hash1==hash2 (OK, play the media, it is on original storage medium)
If hash1!=hash2 (do not play, it is copied to another medium)

Will it work?

[Otanx]

This isn't my strong area in IT, but I think you are making this more complex than it needs to be, or I don't understand what you are doing. Basically you are just creating a licensing mechanism that includes a unique identifier for a system. So you need to come up with your modified standard media format, and your application to read it. Then when creating content the non-protected original file gets loaded to the licensing server. Someone wants the file your application sends the licensing file the unique system ID. This ID can be a hard drive serial number, MAC Address, CPU serial number, etc. Whatever you want. The licensing server then inserts that ID into the original file, and signs the file with a private key. This new file with the ID and signature is given to the client.

When the client wants to play the file the client first checks the signature on the file is valid (client software needs the public key from the server). If the signature is valid it then checks the unique ID in the file against the system. If these match everything is good, and the file can play. If not system was changed, and playing should be denied.

The trick is picking a unique system ID that can be trusted. You specify the Storage medium serial Number which is good. However, number of blocks on the storage medium is going to cause headaches. Systems move files around to avoid bad blocks, and for defagmentation so the number of blocks will change even if a file is not copied just because the system did some cleanup file system tasks in the background.

-Otanx

[ggnfs000]

This isn't my strong area in IT, but I think you are making this more complex than it needs to be, or I don't understand what you are doing. Basically you are just creating a licensing mechanism that includes a unique identifier for a system. So you need to come up with your modified standard media format, and your application to read it. Then when creating content the non-protected original file gets loaded to the licensing server. Someone wants the file your application sends the licensing file the unique system ID. This ID can be a hard drive serial number, MAC Address, CPU serial number, etc. Whatever you want. The licensing server then inserts that ID into the original file, and signs the file with a private key. This new file with the ID and signature is given to the client.

When the client wants to play the file the client first checks the signature on the file is valid (client software needs the public key from the server). If the signature is valid it then checks the unique ID in the file against the system. If these match everything is good, and the file can play. If not system was changed, and playing should be denied.

The trick is picking a unique system ID that can be trusted. You specify the Storage medium serial Number which is good. However, number of blocks on the storage medium is going to cause headaches. Systems move files around to avoid bad blocks, and for defagmentation so the number of blocks will change even if a file is not copied just because the system did some cleanup file system tasks in the background.

-Otanx

thx for input, i actually decided not to use web server for private key storage because that will be complicated. (key can be eavesdropped during download etc., and add'l secure transfer mechanism is needed). I revised and removed the web server mentioning.
so on implementation part, i decided to use cold storage hence the 2nd part of the OP.

No the plan is not about licensing server that user uploads to server etc., i think i confused by mentioning web server part.

The plan is: during the "manufacturing", copy the file to flash device, generate key and enc/hash etc.,
and then distribute it or sell it whatever. That is all, and simple as that. Store the private key used to sign in a secure place.

If blocks counts are unstable such that it can compromise the playability on original device, it can be ignored and other disk characteristics can be used. But I think total block count can be read from USB media, but not sure though. 

[Otanx]

OK, so you are distributing the media as well? Then I think you are on the right track you take the media serial add it to the file, generate a hash of that, add the hash to the start of the file, and then use the private key to sign the entire thing. Then your client software has the associated public key, and uses that to validate the signature. It then removes the hash, generates a new hash of the remaining file and compares it to the stored hash. If they match then compare the media serial numbers. If those match then play the file.

There are a couple weak points in this process. One is looking at the file and figuring out you just added some headers to an MP3 file. Remove those and I have a usable file. Also if I can replace the public key in the client software with my own I can modify and sign files all day long. Finally I can spoof the media serial number that is presented to your client software to match the original media. There is also the compromise of your private key, but that is not given to clients so less of an issue. As you have already stated reverse engineering is outside the scope of this discussion so I will leave it alone.

-Otanx

[ggnfs000]

OK, so you are distributing the media as well? Then I think you are on the right track you take the media serial add it to the file, generate a hash of that, add the hash to the start of the file, and then use the private key to sign the entire thing. Then your client software has the associated public key, and uses that to validate the signature. It then removes the hash, generates a new hash of the remaining file and compares it to the stored hash. If they match then compare the media serial numbers. If those match then play the file.

There are a couple weak points in this process. One is looking at the file and figuring out you just added some headers to an MP3 file. Remove those and I have a usable file. Also if I can replace the public key in the client software with my own I can modify and sign files all day long. Finally I can spoof the media serial number that is presented to your client software to match the original media. There is also the compromise of your private key, but that is not given to clients so less of an issue. As you have already stated reverse engineering is outside the scope of this discussion so I will leave it alone.

-Otanx

Thx for feedback

1. One is looking at the file and figuring out you just added some headers to an MP3 file. Remove those and I have a usable file:

chances are, modifications are severe enough that it can not be restored to be played by standard media player + it is reverse engineering

2. Also if I can replace the public key in the client software with my own I can modify and sign files all day long
that is brute force, for hardened algorithms like sha, rsa, might take thousands of years.

3. Finally I can spoof the media serial number that is presented to your client software to match the original media.
One has to reverse-engineer to find out SN being used. To make it harder, I am planning to use convoluted code (several checks spread throughout the code) and encrypt the validation code itself so that it lives in the unencrypted form only while it is in memory. Still with enough time, it can be figured out, but make it harder and longer to breach.