Mikel Artetxe <[email protected]> writes: > > You could sign the language pairs with your public key when > uploading, > > have the public key in the app, let the app download both language > pair > and signature and check the signature. > > > That doesn't make much sense to me. In your schema the attacker would > also be able to sign his malicious code, as the key would be public > for everyone.
Huh? If the attacker signs with her key, then it's signed with her key, not signed with your key. Then it fails your verification test. Let me try explaining again: Your app has your own public key hardcoded. You sign any language pairs that you upload to your server with your private key. Your app uses the hardcoded public key to verify on download that the pairs have been signed with the corresponding private key. If they are unsigned or signed with some other private key, they will fail the test. An attacker can't change the public key that's in the app without, well, changing the app itself, in which case nothing we can do matters. And an attacker can't get a hold of your private key without breaking into your computer, in which case nothing we can do matters. And an attacker can't use your public key to sign anything, otherwise encryption would not work, in which case nothing we can do matters. This is basically the same thing that happens when Google ships the Play app with some hardcoded list of public keys and use those keys to ensure they're connecting to the correct server for Play Store. Or your browser ships with some hardcoded CA keys to check that they're connecting to the right https server. > (Or you could download language pairs using https and pretend that > the > CA system is safe and that no one who's not authorised can upload > bad > pairs.) > > > Yes, that's why I've said that Benedikt's idea would serve for the > official app, but not for Mitzuli. Mitzuli does not download language > pairs over https, and doing so is not an option for the moment. That's > why I was planning to implement the whole signing mechanism into > Mitzuli, and I suggested that we could reuse that code in the official > app. > > But the MITM issue is unrelated to the issue of storing on SD, > isn't it? > > > More or less. The underlying threat is the same in both cases (an > attacker modifies our bytecode). The only thing that changes is how he > would achieve that: in one case he would replace it in the filesystem > whereas in the other case he would modify it as it is being > downloaded. Signing language pairs would solve both of them. > > (That is, the MITM vulnerability is there regardless of whether > you only > support Android 4.4 or if you implement Benedikt's hash trick.) > > > It is there in Mitzuli, but not in the official app. So there is > certainly no need to worry about it here! OK, makes sense :-) -- Kevin Brubeck Unhammer GPG: 0x766AC60C
signature.asc
Description: PGP signature
------------------------------------------------------------------------------
_______________________________________________ Apertium-stuff mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/apertium-stuff
