Posts Tagged ‘encryption’

Every once in awhile, we talk to people who discover a cryptography library in their chosen language and think this is their magic answer to gain code “security”. They’ll go about using block ciphers on important data without really understanding their purpose.
Like any good business, we like to keep an eye on what our competitors are doing in the security space. Yesterday, a new one showed up on the internet and I was asked to take a look at it by our marketing team. My internal reviews of competitor products help our marketing team compare and contrast our products and approaches to security. They’re often asked pointed questions by potential customers and they like to be prepared with accurate answers. Often, we don’t occupy the same segment of the market or have a completely different approach to solving security problems. Sometimes, reviewing a competitors product shows some gap in our own features or functionality. In this sense, we improve, our competitors improve, and the customer wins. This is largely what good capitalism is all about.
However, yesterday, I was utterly disgusted by the product I reviewed. Their library could be completely decompiled. Their algorithms for communicating with the server were plainly visible. Their license was simple XML block that was encrypted using a simple block cipher. All communication was done over http and the encryption key was the exact same key used to validate a product. In order to validate a product, you were sending the key over an HTTP GET request completely in the clear.
This really highlights the problem with Encryption. Too many people view it as a black box and think it will magically increase security. Employed in the wrong way, it does no such thing. If you don’t protect your keys…If you send secret information in the clear across http…If you don’t protect the source code handling all of your magic algorithms, you’re asking for problems. You’re usually no better off using a simple caesar’s cipher than an encryption algorithm.
In Nitro-LM, we make sure we protect our communication library with either native code, or internal code-hiding algorithms that defeat decompilers. We communicate over http, but encrypt all traffic using RSA public-private keys to ensure that ONLY the receiver can read the data. Underneath that top-level of security, our license and all of our license data is encrypted between 5-10 times with randomized algorithms, keys, and proprietary key-hiding techniques. We instruct our customers on proper key-hiding techniques and how to communicate in a secure fashion with our servers. By utilizing data contained in the license, they can further protect themselves from someone being able to operate their software in a hacked manner.
Encryption in itself is not a silver bullet. Encryption plus knowledge and proper key protection can be a winning combination.
The Online Flex Meetup Group is Organized by John Mason out of Atlanta, GA. His group attracts attendees from all over the USA and the World. We received an Invitation to present to this group on June 10, 2009. The event was recorded and also covered some material that was also presented at the 360|Flex Conference in Indianapolis, IN in May 2009. Enjoy!
We never thought we would ever see this in a licensed commercial software product, but here it is…
In part two, we cover using the Asset Encrypter to encrypt AIR module swfs. This demo also contains a before and after look at the code using a decompiler.
Adobe this week has announced the release of Adobe Flex-3 Builder and Adobe AIR 1.0 (Adobe Integrated Runtime). The playing field for the process of software development and delivery is about to change in some major ways…
Adobe this week has announced the release of Adobe Flex-3 Builder and Adobe AIR 1.0 (Adobe Integrated Runtime). The playing field for the process of software development and delivery is about to change in some major ways…
Continue reading “Licensing Rich Internet Applications (RIA)” »