42 replies to this topic

[Quartz101]

Title says, well, most of it. I'm making an OS, and I plan to add addons. However, is there a way, that they can be 'signed' in a way where the 'certificate' cannot easily be stolen?

[KingofGamesYami]

In short, no.

Anything you do to your program, I (or any halfways decent programmer) could undo. The only thing I can think of is requiring a password upon installation, which is provided in the forum post. But then again, they could easily steal the password as well. You could add comments to your code indicating it's yours... but it'd be simple to remove them before redistributing it.

[Quartz101]

KingofGamesYami, on 28 November 2015 - 09:32 PM, said:

In short, no.

Anything you do to your program, I (or any halfways decent programmer) could undo. The only thing I can think of is requiring a password upon installation, which is provided in the forum post. But then again, they could easily steal the password as well. You could add comments to your code indicating it's yours... but it'd be simple to remove them before redistributing it.

Actually... I came up with an idea. A webserver which can decrypt addon data, but the decryption key is never exposed to the client. There is a 'developer mode' which will allow unsigned addons, but when it's off, addons MUST be encrypted.

[Yevano]

KingofGamesYami, on 28 November 2015 - 09:32 PM, said:

In short, no.

Anything you do to your program, I (or any halfways decent programmer) could undo. The only thing I can think of is requiring a password upon installation, which is provided in the forum post. But then again, they could easily steal the password as well. You could add comments to your code indicating it's yours... but it'd be simple to remove them before redistributing it.

I don't think he's asking whether or not it's possible to prevent the program itself from being stolen, but rather he wants to be able to sign addons in such a way that one can verify the integrity of the addon, but not get a hold of the certificate. I'm no expert in cryptography by a long shot, but I believe what you're looking for is asymmetric encryption. The author would have a private key and a public key, and to demonstrate their authenticity would sign a message and send it to the user, who would then decrypt the message with the public key. If the message is unchanged, then the author is probably who they say they are. If anyone really knows their stuff on this subject, feel free to correct me as I've done minimal research.

Edit: @Quartz Looks like you're thinking in the same vein as I am, so maybe I'm not crazy

Edited by Yevano, 29 November 2015 - 01:00 AM.

[Bomb Bloke]

Yevano, on 29 November 2015 - 12:58 AM, said:

I'm no expert in cryptography by a long shot, but I believe what you're looking for is asymmetric encryption. The author would have a private key and a public key, and to demonstrate their authenticity would sign a message and send it to the user, who would then decrypt the message with the public key. If the message is unchanged, then the author is probably who they say they are. If anyone really knows their stuff on this subject, feel free to correct me as I've done minimal research.

More or less, yeah. Worth noting that certificates aren't involved in the signing process (they're a different can of worms): you simply set up the OS with the public key, and the addon signer with the private one. If the OS can't decrypt an addon with that public key then it knows it didn't come from a trusted source.

This relies on all addons being installed by your OS, and all addon code being inspected before signing to ensure there's no malicious instructions (inspected by you, the developer of the OS, the only one who has the private signing key and is able to sign stuff). If anyone can run any code on a system without your OS's permission (eg by convincing the user to switch to developer mode), then they can likely take full control of it and remove all future signature checks from the code of your OS.

Obviously such compromisation is pretty trivial to pull off if they have physical access to the system, but that's not your concern.

[Quartz101]

Yevano, on 29 November 2015 - 12:58 AM, said:

KingofGamesYami, on 28 November 2015 - 09:32 PM, said:

In short, no.

Anything you do to your program, I (or any halfways decent programmer) could undo. The only thing I can think of is requiring a password upon installation, which is provided in the forum post. But then again, they could easily steal the password as well. You could add comments to your code indicating it's yours... but it'd be simple to remove them before redistributing it.

I don't think he's asking whether or not it's possible to prevent the program itself from being stolen, but rather he wants to be able to sign addons in such a way that one can verify the integrity of the addon, but not get a hold of the certificate. I'm no expert in cryptography by a long shot, but I believe what you're looking for is asymmetric encryption. The author would have a private key and a public key, and to demonstrate their authenticity would sign a message and send it to the user, who would then decrypt the message with the public key. If the message is unchanged, then the author is probably who they say they are. If anyone really knows their stuff on this subject, feel free to correct me as I've done minimal research.

Edit: @Quartz Looks like you're thinking in the same vein as I am, so maybe I'm not crazy

Yeah, that's what I was looking for. Also, I googled asymmetric encryption, and it says anyone can encrypt w/ the public key, but only the private key can decrypt it. Weird...

Bomb Bloke, on 29 November 2015 - 01:32 AM, said:

Yevano, on 29 November 2015 - 12:58 AM, said:

I'm no expert in cryptography by a long shot, but I believe what you're looking for is asymmetric encryption. The author would have a private key and a public key, and to demonstrate their authenticity would sign a message and send it to the user, who would then decrypt the message with the public key. If the message is unchanged, then the author is probably who they say they are. If anyone really knows their stuff on this subject, feel free to correct me as I've done minimal research.

More or less, yeah. Worth noting that certificates aren't involved in the signing process (they're a different can of worms): you simply set up the OS with the public key, and the addon signer with the private one. If the OS can't decrypt an addon with that public key then it knows it didn't come from a trusted source.

This relies on all addons being installed by your OS, and all addon code being inspected before signing to ensure there's no malicious instructions (inspected by you, the developer of the OS, the only one who has the private signing key and is able to sign stuff). If anyone can run any code on a system without your OS's permission (eg by convincing the user to switch to developer mode), then they can likely take full control of it and remove all future signature checks from the code of your OS.

Obviously such compromisation is pretty trivial to pull off if they have physical access to the system, but that's not your concern.

I will say that addons will likely be sandboxed, and they will NOT run with full system-level access. But yeah, that's the most likely way it'll happen. I'm looking for a lua asymmetric encryption algorithm right now, actually.

Edited by Quartz101, 29 November 2015 - 02:30 PM.

[Lupus590]

Quartz101, on 29 November 2015 - 02:27 PM, said:

Yeah, that's what I was looking for. Also, I googled asymmetric encryption, and it says anyone can encrypt w/ the public key, but only the private key can decrypt it. Weird...

You can use either key to encrypt your data but you have to use the opposite key to decrypt. This video explains why you may want to encrypt with either key (or even both types of keys).

Edited by Lupus590, 29 November 2015 - 02:57 PM.

[Bomb Bloke]

Asymmetric is a style used in various scenarios. For example, when generating a shared key for secure online communications, it's the public key used for encryption and the private key used for decryption. The point is that there's two keys, and their capabilities are not the same.

The terms "private" and "public" really mean exactly that, and nothing more. You keep one key to yourself, and you allow the other to be made visible to anyone who wants to use it. Whether you reveal the encrypting key or the decrypting key depends on what it is you're trying to do - prove that only you can produce messages the decryption key can decrypt, or ensure that only you can read messages the encryption key encrypted.

[Quartz101]

After some googling, I learned RSA is the best way for asymmetric encryption. Is there a secure lua RSA thing(not 1lann's) that supports CC, too? Or, of course, I could write up a nodejs thing to do the work for me, with my OS sending the request, but that doesn't seem so secure, and it seems cheaty...

[Yevano]

Quartz101, on 29 November 2015 - 03:46 PM, said:

After some googling, I learned RSA is the best way for asymmetric encryption. Is there a secure lua RSA thing(not 1lann's) that supports CC, too? Or, of course, I could write up a nodejs thing to do the work for me, with my OS sending the request, but that doesn't seem so secure, and it seems cheaty...

After looking around a little, I might also suggest that you first hash the program you mean to send using SHA2, then encrypt the hash with your private key. Send the encrypted hash and the program to the user. To verify integrity, the user only has to hash the program again, decrypt the encrypted hash, and check that the two hashes are equal.

The first thing I stumbled upon was http://luaforge.net/projects/sha1-rsa/ which seems to include the bigint functions required to do asymmetric encryption. I don't think it has its own key pair generation, so you'll have to use a different program for that, but that's a one time thing anyway so not really a big deal I guess.

Edit: Why not 1lann's? Unless his implementation is just incorrect, (even the one I sent you could be, I have no idea) it seems like his would work fine. You just need to make sure you use a different key pair generator, because as he says in his OP, the one he implemented in Lua is very insecure.

Edited by Yevano, 29 November 2015 - 05:10 PM.

[Quartz101]

Yevano, on 29 November 2015 - 05:02 PM, said:

Edit: Why not 1lann's? Unless his implementation is just incorrect, (even the one I sent you could be, I have no idea) it seems like his would work fine. You just need to make sure you use a different key pair generator, because as he says in his OP, the one he implemented in Lua is very insecure.

That's what I meant. The key pair generator is insecure.

[Quartz101]

Also, would it be possible to make a Node.js server to generate the keypairs, and CC gets them?

[Yevano]

Quartz101, on 29 November 2015 - 07:49 PM, said:

Also, would it be possible to make a Node.js server to generate the keypairs, and CC gets them?

I don't see why not. For best security just make sure you send the keys through https.

[Anavrins]

Well, put simply, even with the help of a BigInt library in CC, the amount of time that it would take to do most asymmetric encryption would be off the charts.
1lann's RSA, which is using 256-bits key, is very slow in CC, and not at all secure against cracking on a real computer.

So a good way of doing is using some kind of PHP code do to it for you instead of doing it in CC.
You'd have a separate program to sign the add-ons, and your OS would have code to verify them.

But in the end, your code is still modifiable to the user, and could easily remove that verify portion.

[Yevano]

Anavrins, on 29 November 2015 - 10:21 PM, said:

Well, put simply, even with the help of a BigInt library in CC, the amount of time that it would take to do most asymmetric encryption would be off the charts.
1lann's RSA, which is using 256-bits key, is very slow in CC, and not at all secure against cracking on a real computer.

So a good way of doing is using some kind of PHP code do to it for you instead of doing it in CC.
You'd have a separate program to sign the add-ons, and your OS would have code to verify them.

But in the end, your code is still modifiable to the user, and could easily remove that verify portion.

Am I wrong in thinking that only the key pair generation is really slow, not the actual encryption and decryption? It seems he's already going have a server to generate those, and I don't think encrypting and decrypting a SHA2 hash would take very long.

[RoD]

I was thinking in generating a checksum of the program, uploading it to a webserver and whenever you want to install a program just compare its checksum with the one on the webserver.

[Bomb Bloke]

The time it takes to generate the key pair is mostly irrelevant (as that only needs to be done once, ever), and the time it takes to encrypt the hashes also doesn't matter much (as that only needs to be done once per addon update release). Decryption of addon hashes has to be done once for every time an addon is installed (and is the only time you'd need to do any encryption-related processing within ComputerCraft itself), and I'd be surprised if decryption of, say, a mere sixteen character hash would be too painful to sit through.

RoD, on 29 November 2015 - 11:10 PM, said:

I was thinking in generating a checksum of the program, uploading it to a webserver and whenever you want to install a program just compare its checksum with the one on the webserver.

Not exactly "signing", but truth be told, I'd say this'd be more than sufficient. Heck, just having a paste (controlled by Quartz) with the list of "authorised addon" paste IDs would be sufficient. The difference is that these ways, if someone were to gain unauthorised access allowing them to modify that list, they'd be able to add their own paste IDs / hashes to it (whereas with encryption implemented, they'd also need to get their hands on the private key in order to do it).

Edit:

What am I thinking, if you wanted any form of "addon authorisation" you'd at least need to post the hashes. Otherwise you could be tricked into "authorising" a good addon which could later be "updated" into a bad one.

But let's assume the point is to sign for the sake of signing.

Edited by Bomb Bloke, 30 November 2015 - 12:53 AM.

[Quartz101]

Here's what i've (partially) decided on:
1. Every developer has a unique key.
2. A server on the web will store the keys
3. The SERVER will handle encrypting/decrypting.
4. The addon itself will be encrypted, and the OS will download the key it needs to decrypt it.
5. Only signed/encrypted addons will be ran unless dev mode is on
6. Anyways, the OS will sandbox everything, so you would need root exploit (or a disk) to remove verification
7. And I might have some sort of intergrity checker in the OS itself.

Honestly, is this signing? I don't know. Checksums would be hard to handle. If there is a more 'sign'-y alternative, tell me.

Also, isn't CC really glitchy with HTTPS?

[Anavrins]

Here's how I would do it.
Though I have a strong interest in cryptography, I'm in no way an expert at it, so it is up to you to decide if you trust me or not.

Spoiler

Server Setup:

• Only one keypair should be used, meaning that only you can sign peoples add-ons, yes it may be tedious, but having multiple dev keys would open the possibility for random devs to be able to sign some random malware add-on for someone else.
  
• Server should handle the encryption/decryption (of course)

Signing:

• Singing should be done by hashing the add-on, sending that hash to the server for encryption, joining that encrypted hash (signature) to the unmodified add-on in some way.
  
• Although the add-on source is still in plain-text, nobody will be able to change it without triggering a verification error.

Verifying:

• Verifying should be done by hashing the add-on, reading the add-on signature, send the signature to the server for decryption and comparing if the file's hash matches the server provided hash.
  
• Your OS should refuse any add-on that lacks a proper signature, with the exception of your OS's "dev mode".

Edited by Anavrins, 30 November 2015 - 02:08 AM.

[Bomb Bloke]

Anavrins is summing things up about correctly. There's no way you'd want more than one key pair, and you wouldn't want to hand a unique key to each developer - there's simply no point, since they won't be signing anything!

You also wouldn't bother encrypting entire addons when just a hash would suffice.