none
Source Code Encryption. RRS feed

  • Question

  • Hi,

    I'm not 100% sure whether this is the correct forum to post this question but this is where the knowledgable developers hang around so I'll give a go as I'd really value your inputs; forgive me if it was wrong to post here but I really like some pointers.

    Short story is I've been tasked to think through how to go about protecting source code from say someone simply emailing the code to a competitor. All the developers on our site are all very trustworthy decent people however, and for good reason, our parent company are extremely concerned that developers will steal intellectual property written in the code.  This isn't software protection as in protecting executables, this is at the uncompiled code level.

    OK there is talk of encrypting source code as in it's stored in version control encrypted, it's checked out encrypted, it sits locally on disk encrypted and is then only unencrypted when opened in an IDE. The IDE then has to prevent the text representation from being copied out of the IDE, so no copy and paste for example, no screen dumps, nada, the code is sandboxed into the IDE. 

    I don't think this is possible. I think this is dangerous as imagine losing the encryption key!! and I think this puts the company in a position where a black hat could hold the company to ransom. It seems to me risky....

    So the question or the discussion is this....

    Is there someway to encrypt the code like I described above?
    If there is, do you think it's a safe strategy?
    Is there any other means that you know of to protect source code from being stolen?

    for example what do Microsoft do to protect Windows source code from being posted on the internet?

    I really would value any thoughts you have, thanks for reading
    Thursday, October 15, 2009 6:34 PM

Answers

  • Well, there's no perfect way of doing this.  With Microsoft's Shared Source Initiative, MVP's have access to the entirety of the XP code stack.  It's accessed and viewed online but only when a smart card is present, so physical possession of a smart card is necessary to view the code.  That being said, it's still "copyable" so to speak, and screenshots can be taken  while in a session that was initiated with the smart card. 

    In the end, you just have to make sure that the people you hire are trustworthy, and get them to sign NDA's basically saying that they will not release the details nor source code they're working on at your company. 

    Combined with a signed NDA, some kind of source control could also help legally in a situation where someone steals code and claims it as their own.  Be proactive with measures that would stand up in court, hire trustworthy people and you shouldn't have this problem.

    Personally, I think restricting copy/paste and screenshots, etc, is pretty overkill.  If you can't trust someone enough not to copy something out, you shouldn't hire them. 


    Coding Light - Illuminated Ideas and Algorithms in Software
    Coding Light WikiLinkedInForumsBrowser
    • Marked as answer by Derek Smyth Friday, October 16, 2009 10:20 AM
    Thursday, October 15, 2009 6:51 PM
    Moderator

All replies

  • Well, there's no perfect way of doing this.  With Microsoft's Shared Source Initiative, MVP's have access to the entirety of the XP code stack.  It's accessed and viewed online but only when a smart card is present, so physical possession of a smart card is necessary to view the code.  That being said, it's still "copyable" so to speak, and screenshots can be taken  while in a session that was initiated with the smart card. 

    In the end, you just have to make sure that the people you hire are trustworthy, and get them to sign NDA's basically saying that they will not release the details nor source code they're working on at your company. 

    Combined with a signed NDA, some kind of source control could also help legally in a situation where someone steals code and claims it as their own.  Be proactive with measures that would stand up in court, hire trustworthy people and you shouldn't have this problem.

    Personally, I think restricting copy/paste and screenshots, etc, is pretty overkill.  If you can't trust someone enough not to copy something out, you shouldn't hire them. 


    Coding Light - Illuminated Ideas and Algorithms in Software
    Coding Light WikiLinkedInForumsBrowser
    • Marked as answer by Derek Smyth Friday, October 16, 2009 10:20 AM
    Thursday, October 15, 2009 6:51 PM
    Moderator
  • Well developers need the un-encrypted code to do their actual job so encrypting it doesn't get you any extra security , like david says make 'm sign a NDA when they join its a fairly common practice.

    Thursday, October 15, 2009 7:35 PM
  • thanks David and Ray for posting your thoughts and they are exactly the same as my thoughts. It's a matter of trust.

    Unfortunately I have a horrible feeling the management team of the parent company are going to force something nasty on our development team. Think non developer management sorts dictating and limiting how developers can code. My boss may also be thinking this too and thats why he's asked me to look into it.

    Another way I thought about was limiting what the data the machine can store. No USB sticks, no email, no internet, no network access except to source control. Nothing but code going on to the machine from source control and nothing but code going into source control. A very limited development virtual machine running from a virtual hard drive stored on an encrypted partition. Block all ports out and in except again to source control. Running as a virtual machine means you still have the guest OS to load ebooks and internet searches. Just don't see how to stop copy and paste and screen dumps, I guess something could be done but man!!

    Need to think some more on this... thanks, your input guys was valuable, encrypted source code is not the way forward. Having the employee sign something will not be enough for the parent company; lets just say they have a very good reason *nods* for wanting this security.


    Please if anyone else has anything to add then it will be very welcome.

    It's great to have someone to discuss this with.



    Thursday, October 15, 2009 10:07 PM
  • Well, think about it this way...

    Limit copy and paste, and pretty soon you won't have any developers wanting to work for you anyways.  

    It's a toss-up. 

    Obviously, from what you're describing, the situation has happened before.  The solution isn't necessarily technological.  The best solution here is a legal and HR one.  Perform due diligence when hiring.  Check references.  Don't hire people from unknown or defunct companies. Verify phone numbers are valid businesses when calling references.  Force NDAs.  Sue their heads off if they try to steal the code.  That's about the best you can do. 

    Remember, the people you're trying to technologically restrict aren't normal users.  They're developers.  Hackers.  They can figure out the raw API calls to perform their screenshots, which means you'll have to modify Windows itself to prevent that. 

    Not gonna happen.  You wouldn't like it if it did.  Get an NDA and tighten the HR processes.  Don't overreact. 

    Coding Light - Illuminated Ideas and Algorithms in Software
    Coding Light WikiLinkedInForumsBrowser
    Friday, October 16, 2009 12:38 AM
    Moderator
  • There are companies that sell software to scramble source code (Cloakware is one that comes to mind).  Rendering source code functionally unchanged, but difficult to reverse engineer.  Of course, even source code protected like this can still be used by someone else, and of course it's nearly impossible to change this code, by design.

    I agree with others though.  Going down this path to prevent developers from stealing your code is probably the wrong approach.
    Friday, October 16, 2009 1:02 AM
  • Morning folks,

    David again thanks for the advice and An Anon Coward.

    We the team had a discussion and talked out a few ideas and yip encryption is just not viable, creating a limited machine will limit development capabilities without necessary improving security, we had a few other ideas but nothing seems viable.  The code scrambler idea is risky as well although it might help protect the most intellectual parts of the software if a less trusted developer... you see thats the problem 'a less trusted developer' why would you hire and continue to employee a developer you don't trust.

    Thats what all this boils down to.

    Thanks folks I'm going to close this thread off (although if anyone else wants to add anything then please do) but I really don't think there isn't any real means to force developers to be trustworthy with the code (still going to think on it some more), all we can do is ensure we know if they aren't and ensure they are prosecuted in the event.

    Looking forward to the parent companies recommendation of a way forward.

    Thanks everyone.... you were a great help.


    Edit: I'll mark David's first reply as the answer but I've marked everyone elses contribution as helpful just so everyone gets something.
    Friday, October 16, 2009 10:19 AM