Encrypted GCode Decoder

[netpipe]

feature request aes rsa or something like openssl encrypted gcode processing, each machine could store its own unique rsa key.

https://gist.github.com/thinkerbot/706137 Openssl file encoder

might appeal more to the private sectors and people who want to sell/licence models with the ability to expire. might even make security dongles possible.

[netpipe]

perhaps a smartcard would work better for sending propritary gcodes that only print x ammount of times. or something like oauth ?

also an option to print only encrypted gcode files (for public setting, public interfaces), possibly for pay service.

[Nibbels]

Why should I flash such a firmware? Why should I want to print Gcode which is not sliced for my specific printer? Who would want to handle decryption on a 8bit microprocessor (or 32bit microprocessor) -> You would loose steprate wouldnt you?

Why should I (private customer) ever want to have that as a feature?

What I could like is a Login-Function to a printer using U2F or Smartcard Devices, But I (personally/ATMEGA 2560/8bits) like free Ram much more to increase MOVE_CACHE.

Greetings

[netpipe]

twofish or somekindof xor encryption was ment for 8 bit hardware and needs only 36 bytes of RAM (if the key is stored in EEPROM). it would be plenty fast enough to decode gcode lines from a file without loosing steprate. but the smartcard could do all that instead if it were an issue.

there is more reason to have such features than not to have them, the more obvious ones were stated already.

https://github.com/tecan/GCODE-Tools might be able to encrypt/decrypt pc side. but the firmware would still need that feature too.

https://www.sanfoundry.com/cpp-program-implement-rsa-algorithm/

[repetier]

I think there is a problem in your logic. The firmware needs the decryption key but if the key is known you can also decrypt it on your pc so this is just a fake security. So this only works if firmware is closed source with hidden decyrption key that might even be obscured somehow or with a hardware decryption device that the model seller only knows the key for. But that is no solution in open source firmware and very complicated for a gcode that only fits on a special printer/material combination.

[netpipe]

im not sure why i am meeting opposition on this one its a really great idea that someone will eventually use. technically someone could count the stepper pulses or save the commands to a new file using modified firmware but there are still applications for it.

basically where this would thrive would be a public printer/machine that does stuff for someone that has authorized gcodes and prevents someone running unauthorized files or gcode also could prevent theft of your gcode files. maybe something like oauth was used or some kinda cellphone esp8266 for remote auth.

another advantage would be having the option for rfid/smartcard framework for login like nibbles said. having the option to run it on pc or printer side would provide 2 layers/options of security. but having it firmware side is still the better option.

[Nibbels]

Well, do you remember Region-Codes on DVDs? It sounds exactly like such and therefore I hate it. ^^ It makes printing more complicated and not less complicated.

I still dont really get if you understand the Gcode as "copyright protected part" or as "crappy data which only works well if I dont change a thing in your printer".

[repetier]

I think there is a valid reason to have such a protection. We are quite open but there are always artistsor companies wanting to control how often a sold object license is used as they want to sell e.g. 10 prints maximum. I do not really like this, but i understand people wanting this.

The problem is how to do this so it makes sense. Firmware needs to decrypt and in that task ot could just write unencrypted code to sd card and can print it unprotected. So how can you make such a print secure with open source - and here the answer is just you can‘t. Every programmer can hack such a system in minutes. That is what i wanted to say with my last comment. Only propriatary code can do that and even then a havker could just disassemble the code and modify it again. Same problem just a bit harder to hack.

So that is my information and if you have a solution to this i will happily think about this. Other problem is that hosts already need to decrypt to send the commands, otherwise they do not know what is going on and communication protocol is not made for encrypted binary data.

[SlickNickeL]

A real world scenario.

We have a specialized printer that makes three parts at one time. This machine exclusively makes one part, and can’t use octoprint due to individual extrusion multipliers that must be strictly adhered to per machine with its specific color, and brand of filament. Each printer has an SD card with the gcode for the part on it. If this gcode is ever released to the public domain, the machine becomes useless and sales will plummet. (Who’s going to buy something when you can make it for free). Introduce the (Employee). What keeps the employees from copying a card and releasing it to the public? The part is protected by its inability to be reproduced due to its complexity. No need for a parent. If! Someone decided to attempt to reproduce the part, it wouldn’t be the same and would be substandard, not to mention all of the wasted time that simply wouldn’t be worth just making an actual purchase of the original product. What if a disgruntled worker, decides to release the gcode? This is where some sort of encryption would be necessary. Anybody have any ideas?

[repetier]

Ok, this is a problem and you would solve such a problem with symmetric encryption. Someone creates the encrypted gcode. Now you need the password to make any use of this. So if we talk about your employee - he can copy the sd card or just steal it. If he knows how to start it in company he needs to know the password (so he still can steal it and use his known password) or there must be a way to have the key in a secure enclave. That is how encryption sticks work I guess. So you need the stick to encrypt it and also to decrypt it. That way no one knows the password and you have to steal the stick as well. Or he just leases the stick to decrypt the file and put it back. So next level - password protected encryption stick. I have such a stick to sign certificates. It can only sign when I enter a password before. So connect/enable printer and the keyholder needs to enable encryption with his password. This reduces security to keyholder but the chief is not always available so some others start getting the password as well.

So as long as there are "internal" members there is always a risk. Such things are good to protect data between some end points, but the end points are always the weak spot.

[SlickNickeL]

Our machines have only one file per SD card.

The File name is always init.g so all the employee has to do is push the reset button and the machine starts. If there is an error, (bad first layer) pull card and hit reset. Clear bed and reinsert card. What I do is cancel print, clear bed and then hit reset.

I have considered covering the SD port (custom made screen with permanent card). Only problem here is, if a change has to be made to temperature or extrusion multiplier, the whole screen module has to be pulled. This rarely happens. We try to keep the same manufacturers color in its same position. Sometimes lots change and tweaking is necessary.

Considering a contraption that I have made that has a larger than usual SD port. The SD Card is inserted into a pod. I have a cogged key that rotates a neodymium magnet into the throat of the SD pathway. The card can easily be pulled out to the first notch and then slid sideways then removed. This will momentarily place the SD card over the neodymium magnet which corrupts the file. In order to place the new card back into the machine, the key must be inserted and move the magnet out of the SD card path. It works well. Just a lot of extra expense.

Sent from my iPad

On Dec 11, 2020, at 11:28 AM, repetier notifications@github.com wrote:

 Ok, this is a problem and you would solve such a problem with symmetric encryption. Someone creates the encrypted gcode. Now you need the password to make any use of this. So if we talk about your employee - he can copy the sd card or just steal it. If he knows how to start it in company he needs to know the password (so he still can steal it and use his known password) or there must be a way to have the key in a secure enclave. That is how encryption sticks work I guess. So you need the stick to encrypt it and also to decrypt it. That way no one knows the password and you have to steal the stick as well. Or he just leases the stick to decrypt the file and put it back. So next level - password protected encryption stick. I have such a stick to sign certificates. It can only sign when I enter a password before. So connect/enable printer and the keyholder needs to enable encryption with his password. This reduces security to keyholder but the chief is not always available so some others start getting the password as well.

So as long as there are "internal" members there is always a risk. Such things are good to protect data between some end points, but the end points are always the weak spot.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

[repetier]

Are you sure you can erase a sd card with a magnet? Just know this for magnetic disks to work.

You could make a switch to the sd card detect line instead of pulling sd card.Only thing is on printer start it would still try to mount I think. So maybe sd detect and data line of sd card on a switch. Then you can make it more or less closed, also with tools you still can open it I guess.

[SlickNickeL]

Nope! Just tried it. Didn’t do it. Back to the drawing board.

I Might try shorting the terminals with a button battery? I’m game for a few sparks and fireworks!

If card is drug across 3V contact, it may corrupt the file? The contacts are easy enough to put in line.

I’m sure someone has an idea.

Sent from my iPad

On Dec 12, 2020, at 11:08 AM, repetier notifications@github.com wrote:

 Are you sure you can erase a sd card with a magnet? Just know this for magnetic disks to work.

You could make a switch to the sd card detect line instead of pulling sd card.Only thing is on printer start it would still try to mount I think. So maybe sd detect and data line of sd card on a switch. Then you can make it more or less closed, also with tools you still can open it I guess.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.