Shop OBEX P1 Docs P2 Docs Learn Events
Program security... — Parallax Forums

Program security...

FORDFORD Posts: 221
edited 2008-02-29 18:28 in Propeller 1
What will prevent somebody else getting my program out of a propeller lc256,, and simply copying it to another lc256 to steal my code.
Is there some sort of code protection built into it ?

Cheers,
Chris

Comments

  • rockin_rickrockin_rick Posts: 32
    edited 2006-02-27 03:52
    I don't believe that any code protection is possible...

    I've been thinking about this, too. I wonder if code protection could be had by including the eeprom in the same package or on the same die (if possible). I suppose that this would have to be a future device, as the 'current' one is done...

    Rick
  • FORDFORD Posts: 221
    edited 2006-02-27 04:01
    Because our poducts are low volume, I think·I'll just put a 1wire ds1990 chip and lock the code for each to its id number.

    I would be interested to hear how other people would protect their many hours of work ?
    ·
  • Martin HebelMartin Hebel Posts: 1,239
    edited 2006-02-27 04:10
    My idea is to encase all critical components in a non-conductive hard resin... let them bash it with a hammer to get to it. Though, as a kid, I did grind very slowly away one such 'security' measure.

    -Martin

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Martin Hebel
    Perform a Survey of Electronic Technology Employers - Click here!
    Personal Links with plenty of BASIC Stamp info
    and SelmaWare Solutions - StampPlot - Graphical Data Acquisition and Control
  • FORDFORD Posts: 221
    edited 2006-02-27 04:40
    If its just a matter of copying data out of an lc256, thats even easy for me on a basic level.

    I would be interested to know what Chip would do to protect·the code on the eeprom.
    I'm not being smart, I am genuinely interested in his suggestions here, as it will become a serious issue for some people after they have invested lots of time / money into it.

    I think this question will arise a lot over the next few years, and it may even make some people hesitate a bit if their software is that easy to copy.

    Encapsulation is looking like the go here.

    Cheers,
    Chris
  • BeanBean Posts: 8,129
    edited 2006-02-27 12:11
    Program "encryption" can give you a false sense of security.

    There are places that will retreive code from chips that have if encrypted.

    Sure it may keep a 2-bit hack from copying your code, but if someone wants it they're only a web search away from finding a company that will extract it.

    Bean.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    "SX-Video·Module" Now available from Parallax for only $28.95

    http://www.parallax.com/detail.asp?product_id=30012

    "SX-Video OSD module" Now available from Parallax for only·$49.95
    http://www.parallax.com/detail.asp?product_id=30015

    Product web site: www.sxvm.com

    "Ability may get you to the top, but it takes character to keep you there."
    ·
  • FORDFORD Posts: 221
    edited 2006-02-27 13:05
    Yes Bean,
    Thats right, and I am probably making too big a deal of it, and its no different to what we are doing now with bs2 series stamps, so if its that crucial, encapsulation would be the go.

    I have a million and one other things to ask, but from now, I think I'll leave this forum alone and wait for the official documentation as it is released, then I'll probably only have 2 or 3 questions at the end.

    Cheers,
    Chris
  • Paul BakerPaul Baker Posts: 6,351
    edited 2006-02-27 14:50
    I have mulled over the lack of encrypting code, and have tried to think up with a way to do it given the present architecture. And I have concluded its just not possible. The essential aspect of encryption is keeping your keys hidden from prying eyes. Since the initial boot would be unencrypted, placing any keys there would be visable. Even using some value in the ROM doesn't work, unless it is inaccessable via user programs. I have concluded that truely secure code isn't possible with the chip's present architecture.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    ·1+1=10
  • Kaos KiddKaos Kidd Posts: 614
    edited 2006-02-27 15:28
    It's nearly impossible to secure "open source". No matter how someone devies a security measure, it can be side stepped.
    This is because the code that accesses the security measure is open, therefore readable, and reversable.
    Any devise that uses off chip security can be successfuly hacked. Period, end of report.
    Security HAS got to be part of the HARDWARE design, not a afterthought or software answer.
    Plainly put: any uController's code, if it's stored off chip, can be retrieved via external or internal methods.
    If it can be retrieved, it can therefore be reversed. If it can be reversed, it can be hacked.

    AND, just an FYI:
    If a program can be accessable from a "non authorized source", even if it can't be reversed, like vb6 code can't be decompiled, it can be hacked.
    Time and desire of the hacker are the driving factors.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

    Just tossing my two bits worth into the bit bucket
    KK
    ·
  • Paul BakerPaul Baker Posts: 6,351
    edited 2006-02-27 15:47
    To be fully explict, the line of hardware/software is blurred in this instance. What I think you meant to say was that program security cannot be address by user level software. If it is possible to make a series of addresses in the ROM firmware readable only by the boot strap program, it is possible for the firmware of the propeller to be updated in such a way to make a fairly secure encryption algorithm whose passkey is only accessible through Parallax controlled firmware residing in permanent masked ROM.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    ·1+1=10
  • Kaos KiddKaos Kidd Posts: 614
    edited 2006-02-27 16:09
    Paul:
    Understanding that a rom can be read by any hardware, given the 'correct' setup, no rom is safe from external hardware. Once a rom has power, if you bypass the 'original reading source', it's 100% accessable. No software security can be effective against hardware protection. I do agree with you, "...connot be adressed by user level software...", but that's only the first 1/2 of the issue. That will keep out the 2 - 4 bit hackers. A hacker will all their bits can bypass any software impliment software, no matter if it's at the user level, interpiter level or assembly level. Software is hackable. Even more so if relying on off chip resourses. The only way to keep software secure is to make it part of the hardware. Now, if every instruction contained in the device (user, interpiter and assembly code) were encrypted, and the cpu had instructions for decoding that encryption, things change. But, again, this is hardware. Add to this asm code to agument the hardware, to keep the software hackers out, and now, the code is protected at the hardware and software levels.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

    Just tossing my two bits worth into the bit bucket
    KK
    ·
  • Paul BakerPaul Baker Posts: 6,351
    edited 2006-02-27 16:37
    Im not disputing your assertions, you are correct. But the ROM on the propeller is not accessible via external means (unless there is an undocumented test mode), the only documented way of accessing the on-board propeller ROM is via code running on the Propeller, and any program running on the propeller gains access to the ROM via the hub. If the hub were to prevent access to say the last 4 longs of memory (returning all 00's when the locations are read after the bootstrap has turned control over to the first user cog running spin code), this gatekeeping function should be sufficient for all but the most determined hackers. But just like the SX can still be read when in code protected mode using the proper equipment, there is no bullet-proof method of code security if the hacker has access to the hardware. However, I dont believe there is a mechanism to hide a portion of the ROM software or hardware-wise so the whole discussion is moot anyways.

    Ideally any passkey on the system would not be in addressable rom, but would be a dedicated cell accessible only by a hardware encryption engine (each propeller having a unique passkey). This would require brute force methods of decrypting, or using expensive equipment to read the passkey directly from the exposed silicon.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    ·1+1=10
  • Kaos KiddKaos Kidd Posts: 614
    edited 2006-02-27 18:33
    Paul:
    Hmmm, I like your idea about the last 4 longs in memory...
    If only thoes that could affect that would see it would preserve "open code" and protect a programmer / designer's investment.

    [noparse]:)[/noparse]

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

    Just tossing my two bits worth into the bit bucket
    KK
    ·
  • Paul BakerPaul Baker Posts: 6,351
    edited 2006-02-27 19:17
    Well, the chip is too far along in the process to anticipate any major changes such as this. Also I am sure Chip is fully aware that no matter what steps are taken, a determined enough hacker would be able to find thier way around it. He himself has a machine which can read the operating voltage of any exposed metal layer on an unpassivated die. The passkey location could be covered up by metal layers to make sniffing its value difficult, but if the code is stored in RAM unencrypted, the code could be lifted by probing each cell while the program is loaded in the RAM. In all honesty, unless you design a secure-on-silicon device from the ground up, contemplating all methods of hacking possible, the concept of code protection is just an invisible security blanket.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    ·1+1=10
  • Kaos KiddKaos Kidd Posts: 614
    edited 2006-02-27 19:56
    Paul, That was well said.
    I think I'll quite parts of it on the next lecture I give on security.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

    Just tossing my two bits worth into the bit bucket
    KK
    ·
  • GadgetmanGadgetman Posts: 2,436
    edited 2006-02-27 20:05
    In my collection(somewhere) is something called a Merlin II PDA, (A rebadged TRS-80 PocketComputer ) and the only difference from a normal unit was that it came with a BASIC program loaded into memory(for celestial navigation, if anyone wonders)...
    If you removed the batteries, the code went, too...
    I think they also had a trick that would scramble the code if you tried to list it, but as the unit I have had long since lost power... I wouldn't know...

    Anyway, the only way I can see of securing your code would be to have it on a removeable module that can be connected to the 28/29 pins before booting the machine, then be removed as soon as the machine is up and running.
    Then, just make certain that it has a decent battery-backup, and run like h....

    Anyone tries to read out the program will reset the Propeller and lose the program.
    And if they have to pay for a tech to come and boot it again...

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Don't visit my new website...
  • rockin_rickrockin_rick Posts: 32
    edited 2006-02-27 20:10
    First off, I think that having no code protection is OK for most uses, and shouldn't be much of a deterance for using the propeller. But, I don't think that it unreasonable to expect some code protection, even if it isn't 100% secure, for certain applications. If the code protection requires the hacker to disect the package, then you are going to eliminate almost all of the potential 'hackers'. At this level, it would perhaps cost just as much for the hacker to steal your code (through the use of a specialized company or hardware) as it would to develop their own. It's a deterance factor.

    I equate it (kinda) to a car with it's keys, door locks, ignition lock. Just because I can't 100% eliminate the possibility of someone stealing my car, I'm not going to have a car that the doors don't lock and the ignition is just a 'start' button... (or leave my doors unlocked and the key in the ingition)

    Perhaps (as a future device) there will be a "(mainly)secure propeller", perhaps with the eeprom built it. I don't know the costs/technologies/practicalities of this, but even from a non-security standpoint, having it all in one would be nice.

    I agree that with the current generation of propeller, epoxy encapulation would be the best/only method to provide that deterance factor for those sensitive applications...

    Rick
  • CJCJ Posts: 470
    edited 2006-02-27 20:27
    using spin, wouldn't it be about as secure as a BS2, as the code is compiled down to bytecode that is not published, so to hack it, they would have to figure out the interpreter AND your code

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Who says you have to have knowledge to use it?

    I've killed a fly with my bare mind.
  • TigerTiger Posts: 105
    edited 2006-02-27 20:28
    I think it's safe to say that protecting your Propeller code is impossible. I don't think there is any question that Chip thought about this long before we did and for whatever reason (and I'm sure there was one) he decided not to make provisions for security. It's certainly not a case of his not knowing how to do it. While I personally think this is a huge drawback for those of us that make products, I think we might as well move on to what options we do have. As I see it, about the only thing we can do is put some other protected device in the product and somehow make it a critical component for operation. I grant you this is rather lame security, but I think it's all we have and it's probably enough to keep the honest people honest. The hard core hacker was going to find a way in anyway. shakehead.gif

    ...Tiger
  • Paul BakerPaul Baker Posts: 6,351
    edited 2006-02-27 21:50
    Kaos Kidd said...
    Paul, That was well said.
    I think I'll quite parts of it on the next lecture I give on security.

    Quote away, I won't even charge a royalty fee tongue.gif .

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    ·1+1=10
  • Kaos KiddKaos Kidd Posts: 614
    edited 2006-02-27 22:06
    [noparse]:)[/noparse]

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

    Just tossing my two bits worth into the bit bucket
    KK
    ·
  • PLJackPLJack Posts: 398
    edited 2006-02-27 23:07
    I spent allot of time on this issue regarding PC software.
    The arguments sound the same.

    First, the hackers are not getting "your code". Just the compiled Obj stuff.
    What they end up with can be "hacked with" but no real paradigm code to follow.
    In the end, what is required is a good case when you take the "eprom hackers" to court.

    My recommendation is that after your code is finished, place as many Easter eggs and red herrings that you can without affecting performance or reliability.
    Then encapsulated the eprom and call it a day.

    Once in court it will be easy to make your case by pointing out the Easter eggs in their code.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    - - - PLJack - - -


    Perfection in design is not achieved when there is nothing left to add.
    It is achieved when there is nothing left to take away.
  • Kaos KiddKaos Kidd Posts: 614
    edited 2006-02-28 16:25
    PLJack...
    Well said... but then again, I have less respect for a lawyer then a hacker. At least a hacker has some sort of a give skill.
    But, this is off topic, so I'll drop it here: Point well made!

    ... Next ...

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

    Just tossing my two bits worth into the bit bucket
    KK
    ·
  • stevenmess2004stevenmess2004 Posts: 1,102
    edited 2008-02-29 11:18
    Hmm, seems like code security has been discussed right from the start. Found on the second last page of the forum. smile.gif Can we make one of these a sticky so we don't keep having the same discussions every few months(as interesting as the last one has become)?
  • deSilvadeSilva Posts: 2,967
    edited 2008-02-29 11:25
    We have already some of those "stickies", but - "interesting as they are", to re-phare Steven - they of course lack consistency.

    It would be extremely useful to condense them to a Wiki Page!
    - "5/3.3V"
    - "Code Protection"
    - .....
  • Paul BakerPaul Baker Posts: 6,351
    edited 2008-02-29 18:28
    stevenmess2004 said...
    Hmm, seems like code security has been discussed right from the start. Found on the second last page of the forum. smile.gif Can we make one of these a sticky so we don't keep having the same discussions every few months(as interesting as the last one has become)?
    It's a simple fact that stickies are invisible to 90% of new forum members, they simply don't look at them (I think it's a variation of banner blindness). Placing this thread in the stickies won't stop people from asking.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Paul Baker
    Propeller Applications Engineer

    Parallax, Inc.

    Post Edited (Paul Baker (Parallax)) : 2/29/2008 6:34:23 PM GMT
Sign In or Register to comment.