Open Arena Aimbot

[grey matter]

Excuse me, but with "mods" you mean "mods" like DO NOT LINK[/b]) h t t p s : / / openarena . wikia . com/wiki/Mod]we usually mean them (e.g. legally allowed by apposite SDK license agreement, I think Q3 had something similar), or you mean "hacked" games (e.g. cracks, trainers), that usually are not legally allowed?

I'm talking about legal mods (mods that are compliant with the Quake 3 virtual machine/system calls, which is a cgame/game/q3_ui module, either qvm or shared lib).

I meant that in OA, like in Q3A, anyone can run his own server, with the only link to other servers (and dependency from a third party service) being the master server listing, that anyway does not prevent him to play with his friends (let's keep Q3 punkbuster and cdkey check out for the moment, we are talking of a concept, and of OA mainly). In Quake Live everything is centralized, and without its master server, nothing would work at all, I suppose (but I'm not a lot inside QL architecture, maybe there may exist some workaround I don't know. I don't even know if id software itself runs all the servers, or it relies on third party people).

To be honest, it's been ages since I've used by QL test account. From what I remember you could play offline matches against bots. If that's true, then you have the required server and game logic on your computer as well. It certainly requires some effort to play with your friends with this (cdkey and such), but it should be possible, just like in Q3/OA. The architecture of server+client engine and game logic in cgame, game and ui modules is still the same in QL.

The server can safely assume that a properly generated uuid coming from one and the same ip won't change very often.

Why do you need an uuid then, when you rely on the IP belonging to the very same PC? The only advantage is that you could identify multiple accounts from the same PC/IP. The IP can't be changed anyways, since it's required for network routing to work. If the IP ain't static, then you need a uuid, but then it's also the only way to identify the client and thus fails since the client can just fake it.

This is the sort of assumption that I had when I implemented in my module for B3 called WideBan. Even with the currently unreliable GUID, it's possible to use it when possible to make the banning system a bit more reliable.

You can also read client cvars and binds with a clientside mod (i.e. via cgame.qvm) to generate that kind of fingerprint you're aiming at.

[7]

This is the sort of assumption that I had when I implemented in my module for B3 called WideBan. Even with the currently unreliable GUID, it's possible to use it when possible to make the banning system a bit more reliable. But anyway, spend a lot of time to make a unique GUID still is to me a waste of time since it can be cheated client-side.

The point in generating a guid/uuid from hardware specs is that a server can safely assume it won't change a lot. Randomly generated guids would change with each installation of the client while uuids generated from hardware specs would not, so players with multiple installs (like coders, artists and testers) and players having trouble with the client and reinstalling it a lot would probably get banned with random guids.

[GrosBedo]

- About the perfect humanized bot, yes indeed I talked about those other features, which are critical to detect a cheat. This is what makes the difference between a bot and a human, and as long as no bot can simulate all these features at the same time, we can confidently assume that we can detect them (by a human verification or a sophisticated automated system).

Another example of feature that aimbots don't simulate right now is the wrist movement. There is a great article by the author of the BrainWorks mod on the matter:
http://brainworks-ai.blogspot.com/2008/06/its-all-in-wrist.html

And as a matter of fact, I am pretty sure that the best human simulation currently for OA and Quake games is the BrainWorks mod, but yet it does lack a lot of features (and so it still is detectable), and it does have access to a lot of ingame informations since it's directly plugged in, as opposed to cheats that only hook the game and get much less pertinent data.

- About the SOCKS proxy, you are talking in a theoretical viewpoint, but in practical it's not the case, and indeed the concrete risk is weak compared to the potential high risk. From my own experience, this is not (yet) a concern. Maybe in the future with the democratization of very highspeed broadbands it will become a risk, but for now it's not, since useable SOCKS proxies are very rare.

- About dynamic IPs: indeed this is a concern, but it's highly unprobable that two players share the same dynamic IPs, and in this case they may complaint to remove it. This is indeed the limit of the global banlist, that's why an anti-cheat system may be made in the future...

- About B3 banlist: You can edit the command in B3 so that you require a reason before banning, this is an easy tweak.
And yes you can have a global banlist. For the previous supeR,Servers, this was implemented, so that a player banned on one server was banned on all servers (same for kick and warnings). Also, the banlist was public and subscribable, though noone used it.
Keep in mind that this is a distributed system, unlike Punkbuster which was centralized and maintained by a single entity. Here, you are free to use and contribute to the global banlist, or not. And you can even create your own sub global banlist, that will only apply to a subset of servers (a little like the supeR,Servers: the banlist was global only to those servers, but not for the others, since noone participated...).

- About demos and B3: of course, and there's already a patch to make automated server-side demos for OA, but this is a separate concern. My point was that you can implement it easily in B3 and share it with the banlist. The way you make the demos is up to you.

Anyway about the whole global banlist, I think I must clarify: I don't think we will ever get to a centralized system like Quake 3 and PunkBuster, and this would be quite inadequate with the open spirit of OA. A distributed system is what I have in mind, with a choice of use it or leave it for the admins. This is the most realistic and efficient way to imagine an anti-cheat system currently for OA.

-About client-side security measures: exactly, the client is never to be trusted. That's why everything is done server-side in OA and Quake3. If now we begin to compute things client-side, we can't ever know if these were tampered or not, so better avoid wasting time developping such things.

[GrosBedo]

The point in generating a guid/uuid from hardware specs is that a server can safely assume it won't change a lot. Randomly generated guids would change with each installation of the client while uuids generated from hardware specs would not, so players with multiple installs (like coders, artists and testers) and players having trouble with the client and reinstalling it a lot would probably get banned with random guids.

I see, in this case nice idea, but it would still not have a good false positives / false negatives ratio, because players that intentionnally change their GUID will also probably change their IPs at the same time. So we get back to the starting point...

[GrosBedo]

To be honest, it's been ages since I've used by QL test account. From what I remember you could play offline matches against bots. If that's true, then you have the required server and game logic on your computer as well. It certainly requires some effort to play with your friends with this (cdkey and such), but it should be possible, just like in Q3/OA. The architecture of server+client engine and game logic in cgame, game and ui modules is still the same in QL

It's not that simple: the main point of QL is not the game logic but the serverside logic, which automatically create matchs between players of similar skills, and follow their progress. So in fact, you would lose all the benefits, while having all the cons of a closed system: no editing, no update, and no mod! Because I'm not aware of any SDK for QL yet.

I concur with Gig that OA has a potentially infinite reusability compared to Q3 and QL (QL reusability when there will be no maintenance will be near 0).

[Gig]

To be honest, it's been ages since I've used by QL test account. From what I remember you could play offline matches against bots.

I don't know if there is a way to launch QuakeLive client other than connecting to their web site (maybe there is a way to directly launch the binaries, or an hacker may "fake" that website client invoking), and I haven't checked if you can safely disconnect from the internet after launching the test match against bots.

[grey matter]

- About the perfect humanized bot, yes indeed I talked about those other features, which are critical to detect a cheat. This is what makes the difference between a bot and a human, and as long as no bot can simulate all these features at the same time, we can confidently assume that we can detect them (by a human verification or a sophisticated automated system).

I'm still not convinced that you can tell a lucky shot from one of the current human aimbots. It's suspicious if there are too many of them, but you won't go into great length and detail analyzing each and every shot of every player on a public server (since public servers are the score you suggested. In a local league environment you can control who's playing with which client hard- and software by providing it yourself).

- About the SOCKS proxy, you are talking in a theoretical viewpoint, but in practical it's not the case, and indeed the concrete risk is weak compared to the potential high risk. From my own experience, this is not (yet) a concern. Maybe in the future with the democratization of very highspeed broadbands it will become a risk, but for now it's not, since useable SOCKS proxies are very rare.

Could you please rephrase that, since I don't quite get what you're talking about here.

- About dynamic IPs: indeed this is a concern, but it's highly unprobable that two players share the same dynamic IPs, and in this case they may complaint to remove it.

From my time with T-Online as ISP I can't remember having the same IP twice, which means that someone else (multiple someones infact) must have used them after me.
I haven't heard of ISP tailoring their IPs to specific customers by using things such as login data or modem MAC and as such the risk of multiple different people using the very same IP is real.

- About demos and B3: of course, and there's already a patch to make automated server-side demos for OA, but this is a separate concern.

Not really. Since there's currently no proper way to test the authentificy of demos without a separate demo from another trusted client, you as a server admin can not use a demo provided by some random client as a proof of cheat. If you did, no other admin should use your ban list, since it can contain bogus entries.

Anyway about the whole global banlist, I think I must clarify: I don't think we will ever get to a centralized system like Quake 3 and PunkBuster, and this would be quite inadequate with the open spirit of OA. A distributed system is what I have in mind, with a choice of use it or leave it for the admins.

Okay, we've been talking about two different definitions of a global banlist then. Your distributed banlist only becomes global if each and every server admin opts in to use it, that's why I would not call it global.

The point in generating a guid/uuid from hardware specs is that a server can safely assume it won't change a lot. Randomly generated guids would change with each installation of the client while uuids generated from hardware specs would not, so players with multiple installs (like coders, artists and testers) and players having trouble with the client and reinstalling it a lot would probably get banned with random guids.

Excuse me, but in how far is this of any use with cheaters, where the client and thus its uuid can not be trusted _at all?
It's certainly of use to accurately identify clients who use the official legitimate software. But this is already achieved by the current ioquake3, which stores the data for the guid in a user specific folder, no matter where you install the rest of the game (you can override that behaviour without any hacks, but you might as well flag that behaviour as an attempted cheat attempt, though you can not properly detect it on the server).

[7]

Why do you need an uuid then, when you rely on the IP belonging to the very same PC?

I don't, you need a uuid exactly to take dynamic ips into account.

If the IP ain't static, then you need a uuid, but then it's also the only way to identify the client and thus fails since the client can just fake it.

Even with dynamic ips the client won't change ip more then once every 8 hours or so, so let's say we make a sliding time window of 4 hours for uuid change detection. A modern anti-cheating system is fairly good at identifying aimbots and autoshooters unassisted, so it would ban an autoaiming client's uuid within a few minutes and there would be lots of banned uuids from the same ip within 4 hours.

I see, in this case nice idea, but it would still not have a good false positives / false negatives ratio, because players that intentionnally change their GUID will also probably change their IPs at the same time. So we get back to the starting point...

Yep, you can't make a perfect anti-cheating system, that's a fact, but you can make cheaters jump through so many hoops to cheat successfully, that only the most stubborn ones still think it's worth the effort.

[GrosBedo]

@grey matter:

- About dynamic IPs: I didn't say 2 users, but 2 players. It's highly unprobable that 2 players of OpenArena will share the same dynamic IP. But 2 users in the world yes, the probability is 1.

- About SOCKS proxies: I just meant that if there were many usable SOCKS proxy, it would be a concern, but as of now in 2012, it's still not a concern because there are only a very few SOCKS proxies that can be used for this purpose, and so only a few repeated bans of the same player would lead to a complete ban for this player. He can always find another SOCKS proxy, but will spend days and days to find a few ones, so I think that's ok.

- About demos: I'm not talking about the current demo facility. Someone ported a patch from Smoking Guns to OA, so that server-side demos can automatically be recorded. This same person had a public repository to download these demos as a proof of concept. You can find it on this forum.

[grey matter]

Even with dynamic ips the client won't change ip more then once every 8 hours or so, so let's say we make a sliding time window of 4 hours for uuid change detection. A modern anti-cheating system is fairly good at identifying aimbots and autoshooters unassisted, so it would ban an autoaiming client's uuid within a few minutes and there would be lots of banned uuids from the same ip within 4 hours.

Seems like you didn't read my posts. Assuming that the client is willing to evade an IP ban, he can just reconnect to get a new IP. He can change his uuid at will anyways, so if you assume that a not recently seen uuid from an IP should result in immediate ban, one person could ban most of an entire ISP's IP range just by regenerating his uuid and reconnecting with new IPs all the time.
A proper client might change his IP way more often that just every 8 hours. The ISPs I know only assign the same IP to you for a time span of about one hour. If my modem disconnects on inactivity, I might get dozens of different IPs a day.

Yep, you can't make a perfect anti-cheating system, that's a fact, but you can make cheaters jump through so many hoops to cheat successfully, that only the most stubborn ones still think it's worth the effort.

From what I've seen, this only makes people try harder. You also need to separate the hackers (or crackers) creating the cheat and its users.
It's always an arms race about obscurity and reverse engineering, one that the OA developers do not have energy to participate in.

It's not that simple: the main point of QL is not the game logic but the serverside logic, which automatically create matchs between players of similar skills, and follow their progress. So in fact, you would lose all the benefits, while having all the cons of a closed system: no editing, no update, and no mod! Because I'm not aware of any SDK for QL yet.

If their match-making system is what you're after, this can be implemented in OA as well (the code for stats tracking is already been there). But this requires global infrastructue (player database), which would not longer exists "if Fromhell would decide close the site."

Afaik there's indeed no SDK. But you can edit QL (though not the game logic) by replacing or adding models, textures and maps, even for your own  servers.

[GrosBedo]

Yep, you can't make a perfect anti-cheating system, that's a fact, but you can make cheaters jump through so many hoops to cheat successfully, that only the most stubborn ones still think it's worth the effort.

Indeed, I agree, but the efficiency of the system should be carefully thought before putting too much time in it. If you can implement a quick function to do this and test its efficiency before proceeding to more development, it would be a good idea. But one shouldn't put too much time in it unless there are strong indicators that it will succeed.

[GrosBedo]

If their match-making system is what you're after, this can be implemented in OA as well (the code for stats tracking is already been there). But this requires global infrastructue (player database), which would not longer exists "if Fromhell would decide close the site."

I don't agree: the game is opensource, even if the original infrastructure is down, anyone can take up the project and continue it. This is one of the greatest advantages of opensource systems.

As an example, see GTV: if it was opensource, it would be used on every ioquake3 based game for leagues, or even casual servers. Actually it's dead, because there's no way to enhance it.

Afaik there's indeed no SDK. But you can edit QL (though not the game logic) by replacing or adding models, textures and maps, even for your own  servers.

Missing the ability to edit the game logic is a big limitation, and so I can't see the point to choose QL over another open game. There are so many out there, and some great ones such as OA, why spend so much pain in a closed game?

[grey matter]

- About dynamic IPs: I didn't say 2 users, but 2 players. It's highly unprobable that 2 players of OpenArena will share the same dynamic IP. But 2 users in the world yes, the probability is 1.

Be careful with that statement, I've seen quite a lot people (maybe brothers, parents and their kids) from the same IP address due to NAT. This should not be so much of an issue with IPV6 and zillzions of addresses for private persons as well.

- About SOCKS proxies: I just meant that if there were many usable SOCKS proxy, it would be a concern, but as of now in 2012, it's still not a concern because there are only a very few SOCKS proxies that can be used for this purpose, and so only a few repeated bans of the same player would lead to a complete ban for this player. He can always find another SOCKS proxy, but will spend days and days to find a few ones, so I think that's ok.

Thanks for clarifying! I share your opinion on this, the average lamer will not spend so much time searching

- About demos: I'm not talking about the current demo facility. Someone ported a patch from Smoking Guns to OA, so that server-side demos can automatically be recorded.

I do have copies of both patches; one record demos from client perspective for each client, the other one records serverwide demos and needs more modding for playback.

[grey matter]

I don't agree: the game is opensource, even if the original infrastructure is down, anyone can take up the project and continue it. This is one of the greatest advantages of opensource systems.

As an example, see GTV: if it was opensource, it would be used on every ioquake3 based game for leagues, or even casual servers. Actually it's dead, because there's no way to enhance it.

I don't quite get your point? You could hack the QL binaries to use your server infrastructure and create the required server software by reverse engineering. This happened to quite a few "dead" old games, which are now run as fan projects. Do you mean that it's way more troublesome (and maybe illegal by licenses) than with open source (I obviously agree on that)?

Missing the ability to edit the game logic is a big limitation, and so I can't see the point to choose QL over another open game. There are so many out there, and some great ones such as OA, why spend so much pain in a closed game?

Because it has anti-cheat, global bans, stats and match-making system? Also see above for fan projects, those usually only emerge for great games, where the closedness (is that a word? it's late..) does not matter that much.

Okay, this'll be my final post for today. Sorry for all the late double posts or aggressive or ignorant tone. It's getting late, I'll just fall asleep now

[7]

From what I've seen, this only makes people try harder. You also need to separate the hackers (or crackers) creating the cheat and its users.
It's always an arms race about obscurity and reverse engineering, one that the OA developers do not have energy to participate in.

We don't have a large enough population of players to attract many hackers also

I hope I've shown you it's not about obscurity and that, quite to the contrary, good security shouldn't rely on obscurity but on trust. There can and should be secrets (like private keys), but the algorithms themselves shouldn't need to remain secret for the system to stay secure.

Indeed, I agree, but the efficiency of the system should be carefully thought before putting too much time in it. If you can implement a quick function to do this and test its efficiency before proceeding to more development, it would be a good idea. But one shouldn't put too much time in it unless there are strong indicators that it will succeed.

Agreed, it's still limited. To make it more efficient you'd need a third identifier besides ip and uuid, but that makes only sense if it is supplied by a third party.

You could for instance implement a central signing server that checks if a client with a certain uuid has handed the OA-server it wants to play on a valid certificate. If the client doesn't supply a correct certificate its uuid is banned. If a client acquires a new certificate for its uuid with the signing server, the signing server sends a tempban out to all OA-servers connected to it, so the client can't play online right away but has to wait a few hours after acquiring a new certificate.

@grey matter: the algorithm the signing server uses to generate certificates doesn't need to be secret, but only the key to sign the certificates.

Edit: On second thought, the validity of the certificates doesn't have to be checked by the signing server but the checking could be delegated to the OA-servers themselves. (It's getting late in Europe )

[WaspKiller]

lol.  I love how this topic has blown up from being the sh*t post of a cheater to some serious discussions among lovers of OA.

It's 21:55 for me and time to play so I won't get into the latter posts but I do hope the Devs are following this thread and take away 2 points.

First, an Anti-Cheat System should be included in OA 3.0.  Be it only server-side or whatever.  As with E+, it doesn't need to find all the cheaters.  Simply kicking (not banning) some of the more common and simpler ones is sufficient.  Also, give Admins one or two simple supporting tools like the Wallhack Identifier.  The process of coding and testing may take some time but it has a multiple return on investment.  E+ took months to analyze the raw data from the logs using clean players and all known cheats on special Dev Servers to make sure that clean players were not kicked which is why they recommend using level 3 (out of a 5 level tier). 

Failure to do to will cripple OA's appeal no matter how good the gameplay and visuals are in OA3.  Right now, Combat Arms is losing players to BattleField Play4Free (which uses PB) not because the game sucks but because cheating is at pandemic levels.

In Urban Terror, which has no internal AC System, I have watched the number of active servers and especially players fall dramatically over the past 4 years.  One reason is that 4.1* was released in 2007/12 and UrT 4.2 is taking forever (the last testable release was UrT HD Alpha 0.1 in 2010/12).

But, a major reason is that while the Community has Ban lists (here) and various player tools (here) the lack of a built-in mechanism turns off many players and forces Admins to deal with all the kiddie cheaters as opposed to being able to play/monitor for the serious stuff.

The WildCat Clan, a well known and respected UrT Clan, recently scaled down their more than 60 UrT Servers worldwide (India, Australia, Europe, USA, etc.) to perhaps 10 and had this to say:

"We have decided to lower our support for Urban Terror and with that we will be taking down more than a few servers. The simple fact is that this game does not have a working Anti-Cheat and it doesn't like it will in the near future. We spend all of our time as a clan busting hackers and dealing with childish players and the reward is very little. We have been moving into newer games and we have decided to reduce our server fleet. We will be leaving up a few servers and still accepting new members but we won't have nearly the amount we did. We thank you for your support over the last two years and we hope you continue to use the servers that will remain. I have started taking them down today and will finish up by the end of the week. The site will be in transition for a little bit while we clean everything up but soon the banners will reflect the servers we are keeping."

- |WC|Runamuk - November 10, 2011 - http://wildcatsclan.net/index.php?topic=8400.msg32237#msg32237  (Forum Acct needed to read the original post).



Second, there will always be naysayers.  People who have no substantive and constructive ideas but make a sh*t load of sound and fury and even threaten to leave the game.  This much I know, if you make the effort to provide a level playing field casual players will appreciate it, it will get press** and become known for fairer gameplay, and the game will grow.



*UrT 4.1.1 was release in 2010 but it's mainly new maps and bug fixes.

**Press, for those non-native English speakers, means news or biographic coverage by various gaming sites and general knowledge bases like WikiPedia which indicates for every game whether is has Anti-Cheating software or not.

[Gig]

Sorry for this Off-Topic post. Someone above mentioned server-side demos. I already heard about them, but I don't know anything exact about them. I thought it would be nice to say something about them (writing what they are, what is needed and how to use them -or at least linking an external site which does-) in the wiki page about Demos. Someone of you can do it? Thank you!
(DO NOT LINK) h t t p s : / / openarena . wikia . com/wiki/Manual/Demos#Server-side_demos

[7]

How about that signing server idea?

You set up a server with public/private key encryption to hand out certificates. A certificate consists of the clients uuid/guid, its ip and a UTC timestamp, and the certificate is encrypted with the server's private key.

The OA-server decrypts the client's certificate with the signing server's public key and tests wether the uuids and ips check out and if the timestamp is too old or too young (tempban on new certificate). If the certificate doesn't check out ok the client is simply disconnected.

Pros:
* The client has to request a new certificate when it changes ip, uuid of when its existing certificate has expired.
* The client can't play right along with a new certificate but has to wait unit the tempban on it expires.
* The client can't fake certificates successfully without the signing server's private key.
* The client can't request a lot of certificates in advance because they expire.
* The signing server can detect fraud with lots of certificate requests for different uuids coming from the same ip.

Cons:
* If the signing server goes down (DDOS) or becomes too heavily loaded the party is over and nobody can play online!
* Every player runs into the tempban period at least once a day, when he first starts playing online.
* You have to build a system into the client that requests certificates in advance while playing online, so the client has a new certificate with its tempban period expired before its present certificate expires permanently.
* People with rapidly changing dynamic ips could run into tempban periods now and then.
* The tempban an expiration periods have to be short (minutes rather than hours) so you'll need to hand out lots and lots of certificates.

[Neon_Knight]

Someone should activate the Sago signal.

I have the impression that all of this should be discussed with the ioquake3 guys, as every ioq3 based project (not only OA) might benefit a lot from this.

[GrosBedo]

I have the impression that all of this should be discussed with the ioquake3 guys, as every ioq3 based project (not only OA) might benefit a lot from this.

Indeed, all these ideas are not specific to OA but could be ported to other ioquake3 games as well, or any other game in fact.

I hope I've shown you it's not about obscurity and that, quite to the contrary, good security shouldn't rely on obscurity but on trust. There can and should be secrets (like private keys), but the algorithms themselves shouldn't need to remain secret for the system to stay secure.

I agree to this concept. But you need to always take good care of the clients input and consider them untrustable. But I see your point in making a trust system with certificates.

Your idea of certificates is a good one I think in theory, and it has the huge advantage of being totally transparent for players and admins, there's no overhead. Anyway, the cons have to be watched out, so that we make sure that a part of the players don't get left behind with this system.

@grey matter: I wasn't talking about NAT for SOCKS proxies, but anyway if someone cheat over a NAT network, we can deem him responsible for the NAT, so if other players on this network complaints, they should see directly with the cheater. So anyway NAT is not really a problem that belongs to the admins of servers but which should be managed directly by the NAT owner (everyone is responsible for what he's doing on the network). The point here is that for dynamical IPs, there are very little chance that we penalize a player that never done anything wrong but just inherited a dynamic IP from a previous cheater.

And about QL reverse engineering vs opensource games: yes that's what I mean, it's way more troublesome, but also reverse engineering is limited (I edited GTV myself to make it work for OA, but I'm limited and can't fix everything unluckily nor add important features that are necessary).

@WaspKiller: thank you for your insight, I wasn't aware that this cheating problem was so prevalent in the other communities. Currently we have very few cheaters because the game is considered old and unknown, but more spotlight it will bring, more problems will too.

@Gig: I will add some infos in the section you've pointed out.
/EDIT: done, and I've made the part about video recording too, though it may need some beautifying.

[7]

I think I've substantially reduced problems with my signing server scheme: the signing server should have the option of extending the trust time on a certificate if the client offers it an expired certificate with the same uuid as the client itself has. This means each uuid has to go trough the tempban time only once, which in turn means you can make the tempban and expiration times longer.

For clarity: the tempban time is essential to the scheme, it's the time the OA-servers need before they trust a client's uuid. The goal of the system is to discourage players (read cheaters) from frequently changing their uuid and it does this by punishing them with a tempban every time they do. This allows for more efficient banning on uuid for anti-cheating systems built on top of this scheme.

[grey matter]

The problem I see here is that a rogue server admin can capture other players uuid on his server (by simply querying them from the certificate server) and then impersonate them on other servers (using a hacked client and the captured uuid to request a new certificate for his own IP).
You'd also have to use public key auth for the requests from a client to the certificate server to avoid this.

[GrosBedo]

Then we can simply have 2 keys (read uuid here): one that will only be sent to the certificate server, and one that will be known publicly by game servers. Both would derive from the same secret key, but noone would be able to get one from the other, using one-way functions.

http://en.wikipedia.org/wiki/One-way_function

[7]

Been doing some more thinking

* Extending trust time on a certificate, as I mentioned in my last post, is not a good idea after all. You could request lots of certificates on different uuids in advance and when you get banned you extend the trust time on the next uuid/certificate you requested in advance, breaking the tempban scheme.

* I think GrosBedo's one-way functions are a good way to solve the rogue admin problem. A one-way function basically is a hash-function, so if you make the client send the unhashed uuid to the signing server but a hashed uuid to the OA-server, and make the signing server hash the client's uuid before he puts it in a certificate, you're good. This way the rogue admin only ever sees hashed uuids, but he needs unhashed uuids to request valid certificates. Because all the OA-servers ever see are hashed uuids, they can ban on them just as well as on the unhashed uuids themselves.

[GrosBedo]

New finding that may be useful relating to our discussion about a distributed global banlist: metabans.com

This is a website where you can register, send and manage your bans (with reasons and all, it seems we can even discuss issues directly there), and you can subscribe to other accounts too. Plus there is a B3 plugin to automatically sync your banlists with metabans. This seems to be the perfect medium to share such a distributed global banlist.

Now I don't know very much about this system practically, I will test it out. Anyway, even if it doesn't work out, B3 still has an internal way to make and share such a distributed global banlist.