[Addon Authoring] Digitally signing messages between users of an addon?

[Brusalk]

Hi all,

For a project of mine that I'm considering, I'm interested in the ability to digitally sign messages sent to other users of the addon, such that the receiver can verify the authenticity of the messages being sent.

I've found LibDSA which claims to essentially do what I'm interested in, but I don't have the technical expertise to verify the code that's used, which is leading me to believe I may need to spend time to develop my own DSA decrypt method in pure Lua.

For this, I'm wondering if anyone here has any experience with doing this within WoW, or has maybe used LibDSA before for a project.


I'm guessing this won't get many replies, but I'm looking forward to anyone that, by some miracle, has some experience with doing what I'm thinking about doing.

[Woogs]

This stuff is over my head, but it was really interesting to check out. If you only care about if the implementation is correct, and not how it actually works, you can verify signatures using other programming languages with built in functionality or reliable libraries.

http://www.php.net/manual/en/functio...ssl-verify.php

[SlippyCheeze]

For a project of mine that I'm considering, I'm interested in the ability to digitally sign messages sent to other users of the addon, such that the receiver can verify the authenticity of the messages being sent.

I've found LibDSA which claims to essentially do what I'm interested in, but I don't have the technical expertise to verify the code that's used, which is leading me to believe I may need to spend time to develop my own DSA decrypt method in pure Lua.

For this, I'm wondering if anyone here has any experience with doing this within WoW, or has maybe used LibDSA before for a project.

I'm guessing this won't get many replies, but I'm looking forward to anyone that, by some miracle, has some experience with doing what I'm thinking about doing.

Well, I have some experience with what you are thinking of doing, and my advice would be: I have real trouble imagining anything that is sufficiently important to be worth protecting this way, rather than by, say, using a simple preshared key between addon users. You could automate key generation and exchange, and use an out-of-band verification to check that the key exchange is as expected.

I also wonder what your threat model is? Unless you are trying to protect against Blizzard reading the communication, or implementing some sort of mesh network where untrusted third parties forward messages between the trusting pair, I have trouble seeing the value in this.

In the case of Blizzard-as-attacker, I doubt you can manage what you are after. Since they control the runtime environment completely and totally, and have very strong protections against your stepping outside that control, they can simply modify their runtime to target your addon if they so desire, and do so without you having any mechanism to either detect, or protect, aganist that.

In the case of a mesh network, unless you are also implementing "time delayed messaging" where both parties can be connected only intermittently, your security needs would be better served by using the mesh to negotiate direct communication and, if necessary, some out-of-band mechanism to verify identity of your communicant.

Basically, if someone figures out how to fake the "user" part of a message in a convincing way, there will be many larger problems than your addon being messed with -- and the security bug will be stomped very, very quickly. Even in a public channel such as "RareCoordinator", this is trustable -- the reason that data sharing addons like RC are attackable today is that they do not use identity filtering, and trust any communication from any user. You could, eg, implement blacklisting or whitelisting in RC and achieve the same level of security that DSA signature verified messaging would achieve, but at vastly lower cost.

So, if you try and outline the security model you have -- what you are protecting, from who, and when -- I am happy to try and help you figure out a more appropriate solution to your problem.

Anyway, some technical advice: you almost certainly don't want DSA, which is super-slow, as the primary signature mechanism for this purpose. Unless your message exchange is very low frequency, and you can afford to block for multiple frames doing the verification (or coroutine it, making it even slower), you would need to exchange session keys between users, authenticated with DSA. That key can then be used as part of a faster keyed HMAC or equivalent on individual messages. This will still be very expensive, just not quite so expensive as DSA

[Brusalk]

Hey! Thanks for responding!

I'm indeed interested in implementing a mesh network. However, the rub is that the data which is being sent is data which needs to be verifiable to the receiver that it is from the author.

The catch is that the actual author/signer of the data may not (and likely isn't) the actual source of the data. Thusly, using the mesh to negotiate a direct connection isn't possible.


Basically imagine that some data is being sent across this mesh network. This data is digitally signed by the author, Tim. Eric wants to get this data, but Tim isn't online. However, Steve does have the data that Tim would otherwise send.

I'm interested in allowing Eric to know that the data is actually coming from Tim, even though the data is coming through via Steve.


I was going to use DSA (or something) to allow Tim to sign the data, and then distribute it into the mesh, where Eric can now get the data from Tim and know that it is valid and hasn't been modified in any way.


For my idea, the sensitive data which being sent would alter the execution of the addon, and could potentially allow a third party to make malicious changes. (For example, allowing Steve to steal all of Eric's gold the second Eric enters a mailbox.

- - - Updated - - -

This stuff is over my head, but it was really interesting to check out. If you only care about if the implementation is correct, and not how it actually works, you can verify signatures using other programming languages with built in functionality or reliable libraries.

http://www.php.net/manual/en/functio...ssl-verify.php

That seems painfully obvious to me now. Thanks. :P

I'm guessing that method wouldn't allow me to know if it's been discretely compromised in a way that isn't obvious from just testing a third party source though, yeah?

[Woogs]

The only bad thing it could do is compromise your private key. As long as it doesn't cache your private key somewhere in the Sign() call chain and doesn't pass it to a malicious function, then you should be fine. The source is pretty short; it shouldn't take more than a few minutes to scan.

[SlippyCheeze]

I'm indeed interested in implementing a mesh network. However, the rub is that the data which is being sent is data which needs to be verifiable to the receiver that it is from the author. The catch is that the actual author/signer of the data may not (and likely isn't) the actual source of the data. Thusly, using the mesh to negotiate a direct connection isn't possible. Basically imagine that some data is being sent across this mesh network. This data is digitally signed by the author, Tim. Eric wants to get this data, but Tim isn't online. However, Steve does have the data that Tim would otherwise send.

OK, specifically the time delayed mesh network I mentioned above. That is a good reason why you would want those properties. Are you planning on having Eric and Tim communicate directly at some point earlier in the process, to exchange identity data, or are you mediating that through a third party also? (I kind of assume you are establishing initial trust directly...)

Given the "sending code" part, it sounds like you will have some reasonably large data to send, even post-compression, so you might consider using that initial identity exchange to share a (sufficiently random, or human supplied) key, and then use that for HMAC-SHA1, which should have sufficient security. You could probably jump to HMAC-SHA256 instead if you prefer.

I would suggest you generate those cache tables statically, and simply embed them directly as lua code in your addon. Avoids the high startup cost to generate them in return for some reasonably compressible data, and the same runtime memory use.

Anyway, that requires that Eric and Tim communicate directly once, but never again. (You could even automate this through, eg, the wow mail system, to exchange the key if you prefer -- that allows time-separated communication to share the key while retaining the direct communication for key establishment.)

Good luck.

I'm guessing that [testing with PHP] wouldn't allow me to know if it's been discretely compromised in a way that isn't obvious from just testing a third party source though, yeah?

Correct: it wouldn't avoid the risk that there was a subtle leak or something like that. That said, you could likely audit the code and get reasonable confidence about the behaviour -- DSA shouldn't be insanely huge to implement, even accounting for the need to write bignum handling, etc, in lua. So the library should be of a managable size, I would imagine.

The same is true of the HMAC-SHA1 code I link above, of course, though that is not in the scope of wow as such, so is less likely to be able to do anything hostile in the wow context.

[Brusalk]

OK, specifically the time delayed mesh network I mentioned above. That is a good reason why you would want those properties. Are you planning on having Eric and Tim communicate directly at some point earlier in the process, to exchange identity data, or are you mediating that through a third party also? (I kind of assume you are establishing initial trust directly...)

Given the "sending code" part, it sounds like you will have some reasonably large data to send, even post-compression, so you might consider using that initial identity exchange to share a (sufficiently random, or human supplied) key, and then use that for HMAC-SHA1, which should have sufficient security. You could probably jump to HMAC-SHA256 instead if you prefer.

I would suggest you generate those cache tables statically, and simply embed them directly as lua code in your addon. Avoids the high startup cost to generate them in return for some reasonably compressible data, and the same runtime memory use.

Anyway, that requires that Eric and Tim communicate directly once, but never again. (You could even automate this through, eg, the wow mail system, to exchange the key if you prefer -- that allows time-separated communication to share the key while retaining the direct communication for key establishment.)

Good luck.



Correct: it wouldn't avoid the risk that there was a subtle leak or something like that. That said, you could likely audit the code and get reasonable confidence about the behaviour -- DSA shouldn't be insanely huge to implement, even accounting for the need to write bignum handling, etc, in lua. So the library should be of a managable size, I would imagine.

The same is true of the HMAC-SHA1 code I link above, of course, though that is not in the scope of wow as such, so is less likely to be able to do anything hostile in the wow context.

Hmm..

Is there a way to use a distributed authority, so that there's no one central authority but is instead spread throughout the network?

The more I'm thinking about it, the more I'm thinking that I'm basically developing a P2P network, which I understand the basic concepts of, but I'm not sure about how a P2P network ensures that individual segments aren't tampered with. (I'm specifically referring to a distributed or trackerless P2P network.)

Do you have any experience with those and how they ensure that data hasn't been tampered with?

[SlippyCheeze]

Is there a way to use a distributed authority, so that there's no one central authority but is instead spread throughout the network?

The more I'm thinking about it, the more I'm thinking that I'm basically developing a P2P network, which I understand the basic concepts of, but I'm not sure about how a P2P network ensures that individual segments aren't tampered with. (I'm specifically referring to a distributed or trackerless P2P network.)

Do you have any experience with those and how they ensure that data hasn't been tampered with?

Yup. PGP is a distributed authority -- you publish your public key to the cloud, and someone else grabs it. You use that for establishing a key shared between the two parties. Problem: without some out of band verification, when alice downloads a public key for bob from mallory, mallory could substitute his own key. Then, he can read the communication, and publish another one to bob using the correct public key. Hence needing some form of validation.

Most P2P networks actually don't care very much about tampered segments as such -- they just do something like distribute, eg, a torrent file that contains a hash of all the blocks. That way you have an ability to determine if the segment is correct or not, but not who tampered with it.

That said, I have not recently looked at their protocols, and there might be something in the space that works for you. (You are one hundred percent on the money that what you describe is a P2P network, by the way.

[Deleted]

Establishing source verification between two parties without some sort of pre-shared information (be it automated or passed manually through outside means of communication) or a trusted third party (which is, really, just another form of the former) would be near-impossible - if you don't trust the messenger, and have no reliable information on the other party, how would you be able to verify any information at all?

How one would implement such an initial sharing of information is highly dependent on the addon you're writing. For example, if you have users add each other to some sort of recipient list, you'd establish a system where you need to enter a seven-character "verification code" on both ends (can be anything, even random, maybe even have a "give me a random code" button because people are lazy), then use that verification code to encrypt communication using a secure pre-shared key algorithm of your choice. Additionally, have a "verification check" communication initially that, for example, marks the entry as "established" or w/e so users get positive feedback on the verification code being correct on both ends.

Just going off the top of my head here.

- - - Updated - - -

Just thought of something else. When looking for the public key for a given user (who is uniquely, but not securely, identified somehow - battletag, character+realm, etc, be inventive), ask multiple nodes (more requests mean more security, but also increase the number of users required for your addon to function properly) of the mesh for his public key independently of each other. Compare answers - if they match, then you can be fairly sure that what you have is indeed the genuine public key (or an attacker has taken over a large portion of your mesh already, in which case you're doomed). If they don't match, someone's trying to mess with the keys. Either increase the number of requests and number of matching answers needed, or switch to a secondary method of authentication.

[elcius]

If you are transmitting data between from a secure party (author) through insecure mediums (users) and want to prevent tampering, use the Digital Signature Algorithm.

If you're sending data from one user to another through other users and don't want that data being changed or viewed by transporters, use RSA, although there is no need to do this in wow, since everyone can talk to everyone else directly.

I've found LibDSA which claims to essentially do what I'm interested in, but I don't have the technical expertise to verify the code that's used, which is leading me to believe I may need to spend time to develop my own DSA decrypt method in pure Lua.

You had the right answer in your first post, as far as validation, there is not much to verify, you have a 200 line bignumber class, and like 80 lines for the algorithm.
Only downside is the calculation times, since tables in lua are really slow, however there are plenty of ways to minimize the work load.

Anyway are you just looking for people with experience or do you have an actual question?