Bluray has as you said an extra layer of gunk before you get to the content: B+
As far as I can tell it's an extra bunch of code that can be used to further check the player for compliance before finally decrypting the AACS title key.
That means that bluray is more complicated to play because you have to implement an extra virtual machine to fool the B+ code into thinking that it runs on a real player.
The reason that HDDVD will win, is that it's easier to play for Open Source players and other user-loyal players.
If the attacker already has a level of access to the system that allows both access to the config file (it might only need to be readable by root) and has network access to the database then you have already lost.
If the OP is talking about a webserver then the answer is to simply put the credentials in a config file and secure the machine as usual.
If the machine that the server runs on is trusted then it just reads the config file.
If the machine is under an untrusted users control then a trusted server must be implemented that enforces the limitations needed for that user and the credentials for that service can be stored in a config file on the untrusted client.
The only time you would ever be worried about storing the credentials is if those credentials give access to more functions than you want the user to access.
An example of this couuld be if someone makes a small utility to count the number of open tickets for a given user, but in stead of calling a function that does exactly that on the server, the utility simply gets full access to the database and does its thing.
In the example it would be catastrophic if the user gains access to the credentials because then he could reassign all his tickets to you.
Well, the OP didn't say that you weren't allowed to request a password at boot.
I think most people are missing the point in this question any way, it seems as though the OP wants to let applications access services with all the same credentials and keep those credentials from the user, at this point the you have already lost as that's simply impossible (see DRM).
A better way would be to write a (trusted) server that the (untrusted) clients can talk to in stead of letting the clients talk directly to the backend database and services with the security problems that creates.
Ok, so you use SSL with client certificates for authenticating against the server, but you are worried that the evil doers might simply read the keys right off the disk.
In that case you can do what Apache and openssh does to protect that kind of information:
Encrypt the keys and store them on disk.
When the program starts (maybe it's just a keyholder process) then the user is prompted for a passphrase and the key is stored in memory, if the keyholder sees any processes it doesn't like on the machine (like a debugger) then it simply shuts down.
This means that the keyholder will need to be started by the user every time the system has been booted, but after that everything can be automated.
This would at least mean that the attacker will need to gain access to the machine with all the software running in tact to get to the key, so if he is forced to reboot the machine then you have won.
If you had claimed a few seconds, then that would have been likely as 2.5 seconds is the time it takes to bounce a signal off the moon once.
In two minutes you can boucne a sigal off mars, but think about how small mars looks from this distance, you'd need a very powerful transmitter and a very directional antenna to pick up the signal again.
Think about it; if signals really bounced around for several minutes inside the ionosphere, then all transmissions would be jamming themselves and all radio communication would be impossible.
The only one who needs to keeps his trap shut is the guy who recovers a player key.
Someone should write a guide for this situation so Blabby McFlappy lips doesn't go bragging on the intarweb about his cool crack as soon as he recovers a key.
Bragging about writing a 500 line Java snippet that decrypts AES is fine, although a bit unsurprising, AACS has been documented for years and it's not going to change any time soon.
Telling people where you get title/player keys from is stupid and will only lead to those holes getting closed off.
Bluray and HDDVD are both going to lose, well, that's what we can hope for, EVD looks much more userfriendly.
If one doesn't lose then I'm predicting that it's going to be the one with the best players and most open access to content.
Bluray is more complicated than HDDVD (B+) so HDDVD players can be simpler and easier to make.
Sanctioned players are worthless (unskippable ads anyone?) so the only good players are going to be the unlicensed ones, just like DVD today, as a HDDVD player is easier to make, the best players are going for HDDVD.
Given a player key we can actually play HDDVD today.
To play bluray we first need to build a player emulator that looks like a real player to the B+ trojan.
Funny how Sony seems to release a lot of user-hostile malware trojans with the content they peddle.
You do not use RAID5 for anything other than file systems with large files that need only sequential access.
For databases nothing will hurt performance more than RAID5.
A database will update 13 bits here and there, with RAID5 you need to read all of the (potentially multi-MB) stripe into memory to recompute the parity and then write both the data and the parity.
For a database you will need something without parity, but with redundancy, than means: Mirrors.
If you want more space and more performance you add disks in stripesets and then mirror the stripesets (or stripe mirrors).
You enforce your argument about todays hardware being more than fast enough with that RAID5 crazy talk, but only to a point, because if you had worked with databases too large to fit in memory then you'd know that RAID5 is wrong.
I'd rather say that if you have enough money to fit all of your data into memory then you should do so, after you run out of RAM buying cash then you can start adding nice 15k RPM disks in monsterous RAID0+1 configurations.
MySQL, however, is a nice replacement for a csv file, but it's a piece of shit when compared to any RDBMS that takes ACID seriously.
If you can solve your problem with MySQL then feel free to do so, but invest in a UPS and take frequent backups, because you are going to need both.
... what needs to be done in stead is: 1) Find the player key in stead, it's much more interesting and can be used to find all title keys released until now. 2) Find a way to decrypt title keys without compromising the identity of the player key, so we can keep playing HDDVD movies.
#1 is much harder than just snarfing the title key, because the player key might only be in memory while the title key is being decrypted and that takes a very short amount of time.
#2 might be very easy (one server running in law-less^H^H^H^Hfree contry could do it all, the bandwidth needed is very low).
#2b Alternatively we could set up a peer to peer network where some of the hosts know how to decrypt title keys, each host will anonymize all data about where it got the answer from, that way it will be very hard to track down the hosts that have the player keys.
#1 is made harder and more important because it's very, very cheap for the powers that be to revoke player keys, so they might revoke all windows based player keys once a month and force all windows players to download new executables and keys to be able to play new movies.
The way this will work is that undiscovered player keys are used to decrypt title keys and the title keys them selves are then distributed.
As long as everybody keeps his piehole shut the collection of title keys just grows and grows, maybe even by dynamically requesting a title key before playing a movie.
If a player key is discovered and disabled by the goonsquad then that player key is simply published along with the title keys that it can't be used to obtain, that way the whole key package shinks every time the evil content overlords disable a key.
It's likely that player keys will be discovered with some frequency, so the freedom fighters might choose to publish player keys on their own just to shink the key package.
Someone needs to put together the infrastructure to support title key distribution and some dynamic way of decrypting an encrypted title key.
The registry is a piece of shit compared to plain text config files, there are several reasons for this, but two of the big ones are:
1) Comments, you can actually add comments to text config files. 2) You can use a normal text editor, normal version control (ever tried putting the registry in subversion?) and other well-honed text tools to work with text based config files.
Yeah, I had somewhat the same problem with a few legacy addresses where I'd get the mails forwarded.
What I did was to reject all mails from the old addresses with a message that my new address could be found at http://dion.swamp.dk/ but I take it that's not what you want:)
Why don't you move your company mail server "home"?
Well, ok it's an acronym, but anyway, AACS is built on real crypto tech, not some dinky homebrew like CSS was.
AACS will probably never be 100% broken like CSS, but we might get very close by attacking players and extracting the player keys.
With a player key you can decrypt all HD-DVDs released up until the time when the Motion Picture Ass of America gets learn of your cracked player key.
The funny part is that if you distribute decrypted title keys in stead of the player key itself it's going to close to impossible for the content dictators to figure out what player key you have.
Well, Vista might sell due to the windows tax, but there is no way "premium content" is ever going to popular.
People will quickly learn that "premium content" means that their machine will be screwed up and that there are tons of things that Just Don't Work(tm) with premium content, so they will quickly stop buying it and start pirating the content in stead.
Am I the only one who has noticed that MS is taking a lot of clues from 1984?
War is peace, slavery is freedom, broken is premium; notice how it just fits in?
I'd say my address is well published as well (ff-sd1@partyticket.net) and I get on average 0.5 spam mails pr. day with no filtering.
I use 4 independant RBLs 3 of them are driven exclusively by spamtraps and the last one is spamhouse, the RBLs are combined with greylisting.
Greylisting is very effective due to two things: 1) it effectively tests the senders mail server to see if it's a real mail server. 2) it multiplies the effectiveness of the spamtrap RBLs by giving the spamtraps an extra 30 minutes to catch the spammer.
Now to use greylisting you certainly need to have control over the mail server, but that's just an argument for running your own mail server:)
C/R is a pain in the ass for the sender, so it is seen as impolite by people like me who just want to send email and be done with it.
Look; if you can set off fireworks safely with a cigar then you can set it off just as safely electronically.
If I could be bothered to buy fireworks then I'd most likely set it off electronically, mainly to be at a good distance for viewing.
You'd need to take some primitive precautions to avoid having the controller ignite prematurely, but it's easily handled by a large switch on the main power feed.
If you turn off the power before getting near the fireworks then it's no more dangerous than when transporting the fireworks.
I have programmed for windows for years and was a huge fanboy of NT until they lied about when NT5 would be out (it turned out that 1997 equals 2001 and NT5 equals windows 2000 in MS world), working with MS windows is the cause of yet another reason for me to hate MS:
* MFC/hungarian notation: Whisky Tango Foxtrot!!! Why oh why would anyone ever release such a horrible mess and why hasn't MS been burned to the ground for doing that?
* Defective C++ compilers which contain glaring incompatiblities with the standard that have never been fixed to this day, I guess this comes down to "perverting standards" first post.
It sounds as though you have no idea what MS has done and just thinks of the company as a big cuddly teddybear that plucks money from the outstretched hands of eager customers and that the only reason that people could possbily dislike MS is that they have collected a lot of money.
Nothing could be further from the truth; I in general don't care if a company makes money, unless I happen to own it, so that's not it.
The problem with MS has nothing to do with money or envy.
The problem with MS is that they: * Pervert standards (ActiveX, J++, Kerberos, OfficeXML, aso) * Lie to customers (wait for us, we're the leader) * Lock in customers with secret protocols and formats. * Blackmail non-buyers bosses. * Conduct smear campains against people who'd rather use competing products * Lobby and threaten politicians who are thinking about open source. * Do everything they can to limit customer choice to their own product,
illegally if they have to.
MS is generally a drag on the industry and we would all be better off if it was destroyed.
Slashdot Mirror
Bluray has as you said an extra layer of gunk before you get to the content: B+
As far as I can tell it's an extra bunch of code that can be used to further check the player for compliance before finally decrypting the AACS title key.
That means that bluray is more complicated to play because you have to implement an extra virtual machine to fool the B+ code into thinking that it runs on a real player.
The reason that HDDVD will win, is that it's easier to play for Open Source players and other user-loyal players.
Well, it's as secure as possible.
If the attacker already has a level of access to the system that allows both access to the config file (it might only need to be readable by root) and has network access to the database then you have already lost.
If the OP is talking about a webserver then the answer is to simply put the credentials in a config file and secure the machine as usual.
If the machine that the server runs on is trusted then it just reads the config file.
If the machine is under an untrusted users control then a trusted server must be implemented that enforces the limitations needed for that user and the credentials for that service can be stored in a config file on the untrusted client.
The only time you would ever be worried about storing the credentials is if those credentials give access to more functions than you want the user to access.
An example of this couuld be if someone makes a small utility to count the number of open tickets for a given user, but in stead of calling a function that does exactly that on the server, the utility simply gets full access to the database and does its thing.
In the example it would be catastrophic if the user gains access to the credentials because then he could reassign all his tickets to you.
Hmm, I wonder if that has something to do with the length of time slices for very nice processes?
Did you do that test on a laptop?
Well, the OP didn't say that you weren't allowed to request a password at boot.
I think most people are missing the point in this question any way, it seems as though the OP wants to let applications access services with all the same credentials and keep those credentials from the user, at this point the you have already lost as that's simply impossible (see DRM).
A better way would be to write a (trusted) server that the (untrusted) clients can talk to in stead of letting the clients talk directly to the backend database and services with the security problems that creates.
How?
Please explain exactly how the CPU will know what priority the scheduler has assigned to a given process.
A system with speedstep might turn up the clock rate when it sees that there is a high priority process wanting CPU, but that's not the norm.
Ok, so you use SSL with client certificates for authenticating against the server, but you are worried that the evil doers might simply read the keys right off the disk.
In that case you can do what Apache and openssh does to protect that kind of information:
Encrypt the keys and store them on disk.
When the program starts (maybe it's just a keyholder process) then the user is prompted for a passphrase and the key is stored in memory, if the keyholder sees any processes it doesn't like on the machine (like a debugger) then it simply shuts down.
This means that the keyholder will need to be started by the user every time the system has been booted, but after that everything can be automated.
This would at least mean that the attacker will need to gain access to the machine with all the software running in tact to get to the key, so if he is forced to reboot the machine then you have won.
If you claim that your signal had been flying for just one minute then it would have circled the globe over 400 times:+ %2F+40076+km&btnG=Search ... or it could have bounced between the moon and the earth almost 50 times:+ %2F+360000+km&btnG=Search
http://www.google.com/search?hl=en&lr=&q=c+*+60+s
http://www.google.com/search?hl=en&lr=&q=c+*+60+s
If you had claimed a few seconds, then that would have been likely as 2.5 seconds is the time it takes to bounce a signal off the moon once.
In two minutes you can boucne a sigal off mars, but think about how small mars looks from this distance, you'd need a very powerful transmitter and a very directional antenna to pick up the signal again.
Think about it; if signals really bounced around for several minutes inside the ionosphere, then all transmissions would be jamming themselves and all radio communication would be impossible.
I should have specified, "Everybody"
The only one who needs to keeps his trap shut is the guy who recovers a player key.
Someone should write a guide for this situation so Blabby McFlappy lips doesn't go bragging on the intarweb about his cool crack as soon as he recovers a key.
Bragging about writing a 500 line Java snippet that decrypts AES is fine, although a bit unsurprising, AACS has been documented for years and it's not going to change any time soon.
Telling people where you get title/player keys from is stupid and will only lead to those holes getting closed off.
Bluray and HDDVD are both going to lose, well, that's what we can hope for, EVD looks much more userfriendly.
If one doesn't lose then I'm predicting that it's going to be the one with the best players and most open access to content.
Bluray is more complicated than HDDVD (B+) so HDDVD players can be simpler and easier to make.
Sanctioned players are worthless (unskippable ads anyone?) so the only good players are going to be the unlicensed ones, just like DVD today, as a HDDVD player is easier to make, the best players are going for HDDVD.
Given a player key we can actually play HDDVD today.
To play bluray we first need to build a player emulator that looks like a real player to the B+ trojan.
Funny how Sony seems to release a lot of user-hostile malware trojans with the content they peddle.
I would never have heard of BSG if it hadn't been for being able to get episodes via the net.
Now, If every episode had a embedded, machine readable, verifiable, donation instructions then I would have donated up to 5 USD pr. episode.
The only thing "they" need to do is to realize that piracy can't be stopped, but that it can be used as a very cheap and fast distribution channel.
You do not use RAID5 for anything other than file systems with large files that need only sequential access.
For databases nothing will hurt performance more than RAID5.
A database will update 13 bits here and there, with RAID5 you need to read all of the (potentially multi-MB) stripe into memory to recompute the parity and then write both the data and the parity.
For a database you will need something without parity, but with redundancy, than means: Mirrors.
If you want more space and more performance you add disks in stripesets and then mirror the stripesets (or stripe mirrors).
You enforce your argument about todays hardware being more than fast enough with that RAID5 crazy talk, but only to a point, because if you had worked with databases too large to fit in memory then you'd know that RAID5 is wrong.
I'd rather say that if you have enough money to fit all of your data into memory then you should do so, after you run out of RAM buying cash then you can start adding nice 15k RPM disks in monsterous RAID0+1 configurations.
MySQL, however, is a nice replacement for a csv file, but it's a piece of shit when compared to any RDBMS that takes ACID seriously.
If you can solve your problem with MySQL then feel free to do so, but invest in a UPS and take frequent backups, because you are going to need both.
... what needs to be done in stead is:
1) Find the player key in stead, it's much more interesting and can be used to find all title keys released until now.
2) Find a way to decrypt title keys without compromising the identity of the player key, so we can keep playing HDDVD movies.
#1 is much harder than just snarfing the title key, because the player key might only be in memory while the title key is being decrypted and that takes a very short amount of time.
#2 might be very easy (one server running in law-less^H^H^H^Hfree contry could do it all, the bandwidth needed is very low).
#2b Alternatively we could set up a peer to peer network where some of the hosts know how to decrypt title keys, each host will anonymize all data about where it got the answer from, that way it will be very hard to track down the hosts that have the player keys.
#1 is made harder and more important because it's very, very cheap for the powers that be to revoke player keys, so they might revoke all windows based player keys once a month and force all windows players to download new executables and keys to be able to play new movies.
I've been saying this for a while.
The way this will work is that undiscovered player keys are used to decrypt title keys and the title keys them selves are then distributed.
As long as everybody keeps his piehole shut the collection of title keys just grows and grows, maybe even by dynamically requesting a title key before playing a movie.
If a player key is discovered and disabled by the goonsquad then that player key is simply published along with the title keys that it can't be used to obtain, that way the whole key package shinks every time the evil content overlords disable a key.
It's likely that player keys will be discovered with some frequency, so the freedom fighters might choose to publish player keys on their own just to shink the key package.
Someone needs to put together the infrastructure to support title key distribution and some dynamic way of decrypting an encrypted title key.
The registry is a piece of shit compared to plain text config files, there are several reasons for this, but two of the big ones are:
1) Comments, you can actually add comments to text config files.
2) You can use a normal text editor, normal version control (ever tried putting the registry in subversion?) and other well-honed text tools to work with text based config files.
Yeah, I had somewhat the same problem with a few legacy addresses where I'd get the mails forwarded.
What I did was to reject all mails from the old addresses with a message that my new address could be found at http://dion.swamp.dk/ but I take it that's not what you want:)
Why don't you move your company mail server "home"?
Well, ok it's an acronym, but anyway, AACS is built on real crypto tech, not some dinky homebrew like CSS was.
AACS will probably never be 100% broken like CSS, but we might get very close by attacking players and extracting the player keys.
With a player key you can decrypt all HD-DVDs released up until the time when the Motion Picture Ass of America gets learn of your cracked player key.
The funny part is that if you distribute decrypted title keys in stead of the player key itself it's going to close to impossible for the content dictators to figure out what player key you have.
Well, Vista might sell due to the windows tax, but there is no way "premium content" is ever going to popular.
People will quickly learn that "premium content" means that their machine will be screwed up and that there are tons of things that Just Don't Work(tm) with premium content, so they will quickly stop buying it and start pirating the content in stead.
Am I the only one who has noticed that MS is taking a lot of clues from 1984?
War is peace, slavery is freedom, broken is premium; notice how it just fits in?
I'd say my address is well published as well (ff-sd1@partyticket.net) and I get on average 0.5 spam mails pr. day with no filtering.
I use 4 independant RBLs 3 of them are driven exclusively by spamtraps and the last one is spamhouse, the RBLs are combined with greylisting.
Greylisting is very effective due to two things:
1) it effectively tests the senders mail server to see if it's a real mail server.
2) it multiplies the effectiveness of the spamtrap RBLs by giving the spamtraps an extra 30 minutes to catch the spammer.
Now to use greylisting you certainly need to have control over the mail server, but that's just an argument for running your own mail server:)
C/R is a pain in the ass for the sender, so it is seen as impolite by people like me who just want to send email and be done with it.
It's hard for countries other than the US to threaten the US into getting their chickenboners under control.
I was going to suggest 0xDEADBEEF, but this is better.
Well, no, that list is crap, because it's not in sync with reality.
I have a machine in a range that SORBS thinks is dynamically allocated, but it's not.
Look; if you can set off fireworks safely with a cigar then you can set it off just as safely electronically.
If I could be bothered to buy fireworks then I'd most likely set it off electronically, mainly to be at a good distance for viewing.
You'd need to take some primitive precautions to avoid having the controller ignite prematurely, but it's easily handled by a large switch on the main power feed.
If you turn off the power before getting near the fireworks then it's no more dangerous than when transporting the fireworks.
Don't be such an alarmist.
Oh and I almost forgot:
I have programmed for windows for years and was a huge fanboy of NT until they lied about when NT5 would be out (it turned out that 1997 equals 2001 and NT5 equals windows 2000 in MS world), working with MS windows is the cause of yet another reason for me to hate MS:
* MFC/hungarian notation: Whisky Tango Foxtrot!!! Why oh why would anyone ever release such a horrible mess and why hasn't MS been burned to the ground for doing that?
* Defective C++ compilers which contain glaring incompatiblities with the standard that have never been fixed to this day, I guess this comes down to "perverting standards" first post.
It sounds as though you have no idea what MS has done and just thinks of the company as a big cuddly teddybear that plucks money from the outstretched hands of eager customers and that the only reason that people could possbily dislike MS is that they have collected a lot of money.
Nothing could be further from the truth; I in general don't care if a company makes money, unless I happen to own it, so that's not it.
The problem with MS has nothing to do with money or envy.
The problem with MS is that they:
* Pervert standards (ActiveX, J++, Kerberos, OfficeXML, aso)
* Lie to customers (wait for us, we're the leader)
* Lock in customers with secret protocols and formats.
* Blackmail non-buyers bosses.
* Conduct smear campains against people who'd rather use competing products
* Lobby and threaten politicians who are thinking about open source.
* Do everything they can to limit customer choice to their own product,
illegally if they have to.
MS is generally a drag on the industry and we would all be better off if it was destroyed.