I've been thinking of a protocol aimed at addressing the problem of bank security. I present StarFriend. StarFriend is designed to ensure banks are generated during online gameplay and not edited afterwards. StarFriend is not an encryption protocol, but an integrity check producing a signature similar to the bank verify function, but unlike the bank's signature a StarFriend signature can only be generated during online gameplay with other players. This means a player can't make a hacked copy of the map and save their own changes locally.
The principle behind StarFriend is that no third party exists during gameplay to sign bank data. Thus players are free to alter banks after gameplay has ended. StarFriend asks players in the game to sign each others data. Thus the players in the game (your ‘friends’) vouch that the bank was generated during gameplay by signing it with their secret keys. This means that a potential cheaters needs to have compromised the accounts of a certain minimum number of players before they can break StarFriend. StarFriend addresses this problem through the use of session keys, keeping each individual player’s secret key safe. Since session keys expire after one use, even if it is stolen through the use of a memory editor, it becomes useless. Only players that collaborate with each other can break StarFriend by sharing their secret keys. In this case, when caught, all the cheaters are exposed from one offense.
In addition, StarFriend can facilitate a banning procedure that does not require the map to store any information about the offenders. If the protocol is implemented across many maps, an offense in one map can ban players across all the maps that use StarFriend without the need to cross communicate. It can prove to be an effective deterrent since cheating is difficult, can be traced and the offenders quickly banned without the need to update any data between maps.
StarFriend is not implemented yet and there are several difficulties that must be overcome before it can come into effect. This is an overview of the protocol.
Please refer to the figure for details.
1. An external server must assign each player who uses StarFriend a secret key. This key is only known to the server and the player and is never revealed. It will most likely exist in an encrypted form on the hardrive of the player, whose security is overseen by a third party program. The secret key is unique to each player and it is important that the owner of the StarCraft 2 account name is assigned the right key and its security protected. The secret key only has to be assigned once.
2. The third party program will then periodically create session keys signed with the player’s secret key. These are written to a bank file so that they may be accessible during gameplay. The game will never have access to the secret key and it is infeasible to guess the secret key from the session key. Only the player and the server know if the session keys are valid as this requires knowledge of the secret key.
3. During gameplay, the game will generate data to save into the bank. Once the bank file must be saved, a digest is generated.
4. The hash is signed by the session keys of the other players in the game to form the authentication certificate. This is the key step that ensures the bank file is valid, since outside of the game, the player won’t have access to the session keys of the other players. A copy of this certificate is also kept with each of the other players. These are all then saved to a bank and an external program sends these to the server. Alternatively, the entire bank may be sent to the server, so the server can gather information about the player’s session (also useful for tracking cheating).
5. The server will then verify the session keys of the other players to see that they are still valid. The server will also check if the session key has been used before. If the signatures are valid and match the certificates the other players sent (if they are sent), the server will sign the certificate with its own private key (known only to the server). The public key is stored in the map. The signed bank will then be returned to the owner, most likely done by a third party program. If the player is banned, the server will refuse to sign the bank, or sign it in a way so the map will know the player was banned and display the appropriate message.
6. When the player wishes to play again, the map will check with the server’s private key to see if the bank has been signed. If the signature is valid, the player is authenticated.
As can be seen, the only information the map needs to store is the public key of the server. The security of this system mainly relies on the integrity of the secret keys. It only works if the majority of people are non-cheaters and keep their keys safe. Since everyone in SC2 can have only one active username per account and the price of cheating is being banned, this is not hard to imagine.
As for the feasibility of this protocol to be used in game, several factors must be considered. First is the distribution of secret keys. These are player specific, so there must be some way to authenticate each player. One way might be through a chat bot, similar to how people sign up for accounts on IRC channels. The player could be given a password that allows them to connect to the web server to retrieve their secret key.
The generation of the session keys and server signing the certificate can be all handled seamlessly with an external program that modifies bank files. Since bank files are only loaded into the cache at map init, modifying them at runtime should not affect Warden. This program does not rely on modifying or reading any game memory. Writing the program itself is trivial.
The protocol will require several security algorithms, including a hash function, and assymetric key encryption. The computational cost must be taken into account. For the generation of the digest, sha-256 will most likely be applied on the contents of the bank. Verification of the certificate returned from the server will require assymetric key encryption. This will most likely be RSA, using a very small exponent (3) and a 1024-bit key if possible. Signing of the hash by the players can be done using AES-256, since the session keys are unknown to the other players and can be generated by the server if the seed for the key’s generation is also sent. Overall this might cause a bit of lag, but should be feasible.
Thus the only overhead for a player wishing to use StarFriend is registering for a key and having the program run in the background (which does not hack into the game). And all the map maker needs to have is the StarFriend library (yet to be written) along with the server’s public key.
tl;dr: StarFriend provides good security against tampering with banks. Requires running some programs in the background and can’t be implemented just yet due to problems of secret key distribution.
why the hell would any player run third party tools.... just to play a map?
any ums that required me to be running a third party tool in the back ground with internet access equals me staying clear of it.
not to mention most players ... that would join a game requiring this online... would have no idea they need the tool...
how would you handle players not runnign the tool
secondly you say you havent even implemented the process for this yet so a couple things
Is it possible to modify the bank file while its in use by the game
this would basically require deditcated servers for signing "keys" for the thrid party tool ( i think that right there = fail for most people)
Cheating in UMS maps does not = cheating... only in ladder.
What happens when i make a my own third party tool, that overwrites the local key you generate (so that I would intentionally corrupt other players keys) =)
what happens when I make my own tool that floods your dedicated server with bad requests
from what your saying here (is it required that each players 3rd party tool needs to communicate between each player... will it be writing all the players IP's locally)... this is even more of a security issue if you ask me....for the players anyways
not to mention most players ... that would join a game requiring this online... would have no idea they need the tool...
how would you handle players not runnign the tool
This is why I proposed the World of Starcraft project to implement it. If a big popular mod incorporates, then players will adopt it and the rest of the lesser known maps will then be able to utilize all the features that StarFriend provides. Initially the app would be optional, but as its adoption rate goes up, it should become required. OR, saving could be disabled until the player installs the app, providing a strong incentive for all players to install it.
It is also possible to implement this protocol without third party tools, but it would require the player to manually upload their bank signatures to the server for signing (pretty much a dead end).
Additionally since there's no way to change maps ingame yet, a mod like World of Starcraft might have to upload their maps separately to battle.net if they want to have a large mmo. This poses a problem, since you can't share banks across maps from ingame, you have to copy them manually. No one is going to be copying banks manually after each game... Thus, players might want to have a third party app to do this seamlessly and it may as well also incorporate StarFriend.
Even dota used used apps to ban players and they were widely adopted. I know it's not kosher to use a third party program, but you must be able to communicate with a trusted third party for a security scheme to work.
You also get much more functionality besides security by using the app. For instance, you can send player's scores or Elo to the server and have it update stats. It can also be used to collect statistics about gameplay. It's a lot of functionality for a small price that many mods can benefit from.
secondly you say you havent even implemented the process for this yet so a couple things
Is it possible to modify the bank file while its in use by the game
It is possible to modify bank files at any time. The game simply loads them during map init into the cache and never accesses them after that except to save data. I highly doubt Warden will look for programs modifying bank files since this does not affect gameplay. Once they are loaded, no alterations from the bank file can be communicated to the game. StarFriend does not rely on any communciations to the external server during gameplay, only after a game has finished.
this would basically require deditcated servers for signing "keys" for the thrid party tool ( i think that right there = fail for most people)
It would require one master server yes. It does not have to be a dedicated socks connection though. Even Mapster can host this server (provided it can handle the volume of inflowing data), since it would require at most an SQL database and some php.
Cheating in UMS maps does not = cheating... only in ladder.
This implementation is not foolproof, if there's 5 hackers and StarFriend only requires 5 players for signing on your map, then they can generate any stats they want and send them to the server. However, this requires you have 5 friends who are willing to give out their keys. To prevent people from doing this, you can threaten them with a ban. If the server stores all banks in its archives, then you can review potential cheating cases and ban the offenders. Thus the moderaters of the StarFriend server can deny gameplay for any player that abuses the system in any map that uses the protocol.
What happens when i make a my own third party tool, that overwrites the local key you generate (so that I would intentionally corrupt other players keys) =)
Your secret key can be signed by the server before you receive it so there's a way to determine if they are real. However, for the session keys I have not yet devised an algorithm to ensure their authenticity (however it is not possible to alter someone elses key that is not your own), but perhaps signed session keys could be requested from the server instead of generating them from secret keys stored locally. There's also still some ambiguity on how to handle/detect malicious players and mapmakers (who do intentional alterations to the implementation of the algorithm) who only wish to corrupt other players data or try to get them intentionally flagged.
what happens when I make my own tool that floods your dedicated server with bad requests
This is a denial of service attack. Every server in the world is prone to this. You could try to write an application right now that floods the forum with bad requests, but I doubt that will bring it down.
from what your saying here (is it required that each players 3rd party tool needs to communicate between each player... will it be writing all the players IP's locally)... this is even more of a security issue if you ask me....for the players anyways
The app does not communicate between players, only between the players and the server. Only the map communicates data between players, which is saved to their bank, which in turn is read by the app.
Hope that clarifies it. The real issue though is secret key distribution. There's no way yet to authenticate that the person communicating with the external server is indeed the owner of the battle.net acc through which they are playing with.
Well props if it works out but personally I think gamers are too lazy to do the 3rd party thing. We just need banks on blizz's servers... but yeah I do say good luck with this if you can get it to go :D
I've been thinking of a protocol aimed at addressing the problem of bank security. I present StarFriend. StarFriend is designed to ensure banks are generated during online gameplay and not edited afterwards. StarFriend is not an encryption protocol, but an integrity check producing a signature similar to the bank verify function, but unlike the bank's signature a StarFriend signature can only be generated during online gameplay with other players. This means a player can't make a hacked copy of the map and save their own changes locally.
The principle behind StarFriend is that no third party exists during gameplay to sign bank data. Thus players are free to alter banks after gameplay has ended. StarFriend asks players in the game to sign each others data. Thus the players in the game (your ‘friends’) vouch that the bank was generated during gameplay by signing it with their secret keys. This means that a potential cheaters needs to have compromised the accounts of a certain minimum number of players before they can break StarFriend. StarFriend addresses this problem through the use of session keys, keeping each individual player’s secret key safe. Since session keys expire after one use, even if it is stolen through the use of a memory editor, it becomes useless. Only players that collaborate with each other can break StarFriend by sharing their secret keys. In this case, when caught, all the cheaters are exposed from one offense.
In addition, StarFriend can facilitate a banning procedure that does not require the map to store any information about the offenders. If the protocol is implemented across many maps, an offense in one map can ban players across all the maps that use StarFriend without the need to cross communicate. It can prove to be an effective deterrent since cheating is difficult, can be traced and the offenders quickly banned without the need to update any data between maps.
StarFriend is not implemented yet and there are several difficulties that must be overcome before it can come into effect. This is an overview of the protocol.
Please refer to the figure for details.
1. An external server must assign each player who uses StarFriend a secret key. This key is only known to the server and the player and is never revealed. It will most likely exist in an encrypted form on the hardrive of the player, whose security is overseen by a third party program. The secret key is unique to each player and it is important that the owner of the StarCraft 2 account name is assigned the right key and its security protected. The secret key only has to be assigned once.
2. The third party program will then periodically create session keys signed with the player’s secret key. These are written to a bank file so that they may be accessible during gameplay. The game will never have access to the secret key and it is infeasible to guess the secret key from the session key. Only the player and the server know if the session keys are valid as this requires knowledge of the secret key.
3. During gameplay, the game will generate data to save into the bank. Once the bank file must be saved, a digest is generated.
4. The hash is signed by the session keys of the other players in the game to form the authentication certificate. This is the key step that ensures the bank file is valid, since outside of the game, the player won’t have access to the session keys of the other players. A copy of this certificate is also kept with each of the other players. These are all then saved to a bank and an external program sends these to the server. Alternatively, the entire bank may be sent to the server, so the server can gather information about the player’s session (also useful for tracking cheating).
5. The server will then verify the session keys of the other players to see that they are still valid. The server will also check if the session key has been used before. If the signatures are valid and match the certificates the other players sent (if they are sent), the server will sign the certificate with its own private key (known only to the server). The public key is stored in the map. The signed bank will then be returned to the owner, most likely done by a third party program. If the player is banned, the server will refuse to sign the bank, or sign it in a way so the map will know the player was banned and display the appropriate message.
6. When the player wishes to play again, the map will check with the server’s private key to see if the bank has been signed. If the signature is valid, the player is authenticated.
As can be seen, the only information the map needs to store is the public key of the server. The security of this system mainly relies on the integrity of the secret keys. It only works if the majority of people are non-cheaters and keep their keys safe. Since everyone in SC2 can have only one active username per account and the price of cheating is being banned, this is not hard to imagine.
As for the feasibility of this protocol to be used in game, several factors must be considered. First is the distribution of secret keys. These are player specific, so there must be some way to authenticate each player. One way might be through a chat bot, similar to how people sign up for accounts on IRC channels. The player could be given a password that allows them to connect to the web server to retrieve their secret key.
The generation of the session keys and server signing the certificate can be all handled seamlessly with an external program that modifies bank files. Since bank files are only loaded into the cache at map init, modifying them at runtime should not affect Warden. This program does not rely on modifying or reading any game memory. Writing the program itself is trivial.
The protocol will require several security algorithms, including a hash function, and assymetric key encryption. The computational cost must be taken into account. For the generation of the digest, sha-256 will most likely be applied on the contents of the bank. Verification of the certificate returned from the server will require assymetric key encryption. This will most likely be RSA, using a very small exponent (3) and a 1024-bit key if possible. Signing of the hash by the players can be done using AES-256, since the session keys are unknown to the other players and can be generated by the server if the seed for the key’s generation is also sent. Overall this might cause a bit of lag, but should be feasible.
Thus the only overhead for a player wishing to use StarFriend is registering for a key and having the program run in the background (which does not hack into the game). And all the map maker needs to have is the StarFriend library (yet to be written) along with the server’s public key.
tl;dr: StarFriend provides good security against tampering with banks. Requires running some programs in the background and can’t be implemented just yet due to problems of secret key distribution.
@SexLethal: Go
Looks interesting. I`m curious to see what S3ius might think of it.
why the hell would any player run third party tools.... just to play a map?
any ums that required me to be running a third party tool in the back ground with internet access equals me staying clear of it.
not to mention most players ... that would join a game requiring this online... would have no idea they need the tool...
how would you handle players not runnign the tool
secondly you say you havent even implemented the process for this yet so a couple things
This is why I proposed the World of Starcraft project to implement it. If a big popular mod incorporates, then players will adopt it and the rest of the lesser known maps will then be able to utilize all the features that StarFriend provides. Initially the app would be optional, but as its adoption rate goes up, it should become required. OR, saving could be disabled until the player installs the app, providing a strong incentive for all players to install it.
It is also possible to implement this protocol without third party tools, but it would require the player to manually upload their bank signatures to the server for signing (pretty much a dead end).
Additionally since there's no way to change maps ingame yet, a mod like World of Starcraft might have to upload their maps separately to battle.net if they want to have a large mmo. This poses a problem, since you can't share banks across maps from ingame, you have to copy them manually. No one is going to be copying banks manually after each game... Thus, players might want to have a third party app to do this seamlessly and it may as well also incorporate StarFriend.
Even dota used used apps to ban players and they were widely adopted. I know it's not kosher to use a third party program, but you must be able to communicate with a trusted third party for a security scheme to work.
You also get much more functionality besides security by using the app. For instance, you can send player's scores or Elo to the server and have it update stats. It can also be used to collect statistics about gameplay. It's a lot of functionality for a small price that many mods can benefit from.
It is possible to modify bank files at any time. The game simply loads them during map init into the cache and never accesses them after that except to save data. I highly doubt Warden will look for programs modifying bank files since this does not affect gameplay. Once they are loaded, no alterations from the bank file can be communicated to the game. StarFriend does not rely on any communciations to the external server during gameplay, only after a game has finished.
It would require one master server yes. It does not have to be a dedicated socks connection though. Even Mapster can host this server (provided it can handle the volume of inflowing data), since it would require at most an SQL database and some php.
This implementation is not foolproof, if there's 5 hackers and StarFriend only requires 5 players for signing on your map, then they can generate any stats they want and send them to the server. However, this requires you have 5 friends who are willing to give out their keys. To prevent people from doing this, you can threaten them with a ban. If the server stores all banks in its archives, then you can review potential cheating cases and ban the offenders. Thus the moderaters of the StarFriend server can deny gameplay for any player that abuses the system in any map that uses the protocol.
Your secret key can be signed by the server before you receive it so there's a way to determine if they are real. However, for the session keys I have not yet devised an algorithm to ensure their authenticity (however it is not possible to alter someone elses key that is not your own), but perhaps signed session keys could be requested from the server instead of generating them from secret keys stored locally. There's also still some ambiguity on how to handle/detect malicious players and mapmakers (who do intentional alterations to the implementation of the algorithm) who only wish to corrupt other players data or try to get them intentionally flagged.
This is a denial of service attack. Every server in the world is prone to this. You could try to write an application right now that floods the forum with bad requests, but I doubt that will bring it down.
The app does not communicate between players, only between the players and the server. Only the map communicates data between players, which is saved to their bank, which in turn is read by the app.
Hope that clarifies it. The real issue though is secret key distribution. There's no way yet to authenticate that the person communicating with the external server is indeed the owner of the battle.net acc through which they are playing with.
@SexLethal: Go
Well props if it works out but personally I think gamers are too lazy to do the 3rd party thing. We just need banks on blizz's servers... but yeah I do say good luck with this if you can get it to go :D
Oh, I tought that point 3 was: PROFIT! xD