December 19, 2012 By Larry Karisny
Paul “Prem” Sobel is a Cal Tech master of science in electrical engineering and has dedicated a 40-year career to protecting mission-critical systems.
He worked with IBM, NASA, Northrop and Intel before launching MerlinCryption LLC. He developed an exponentially stronger encryption with variable key length called the Smart-World’s Smart-Encryption.
In this edited interview, Sobel discusses encryption and other security technologies and critical infrastructure vulnerabilities.
Where are we today in encryption methodologies architecture?
|
Paul "Prem" Sobel, Cal Tech master of science in electrical engineering |
Since World War II, increasingly sophisticated encryption algorithms have been developed with early keys sizes starting at 16 bits and growing to 512 bits. Computer speed, with use of statistical analysis, cryptanalysis, mathematical and brute force techniques have broken, and will continue to break, these encryption algorithms.
Where do you see current major legacy encryption architectures in supporting future requirements?
DES, RSA, SSL and AES algorithms produce simple key strands, which continually repeat in cyphertext.
Current encryption methods also require that keys are transmitted by known mechanisms between end points, which are easily intercepted or spoofed. These two inherent weaknesses explain why a criminal’s attack of choice is against the key. The next generation of encryption must eliminate these two major risks. The new Anti-Statistical Block Encryption (ASBE) utilizes variable-length keys that scale between 2008 bits and 2 GB, which are reinforced by variable-length passwords up to 64KB.
The ASBE method uses a random data generator that generates-destroys-recreates keys and passwords on demand, making key/password transfer between end points unnecessary. The communication and storage of encryption keys and passwords are also not needed, which circumvents criminal interception.
Future requirements will also dictate a more simple and inexpensive key management system. Today’s Public Key Infrastructure (PKI) is economically and operationally an albatross. Research shows that organizations spend between $47 and $5,921 for the creation, distribution and maintenance of each PKI key in use. PKI management involves certificates, registration authority, directory management, central key deposit, external validation and protocol. Future encryption methods must find alternatives to secure key communication and management.
Can Intrusion Prevention System (IPS) security put us on a catastrophic path of the whole security architecture collapsing?
IPS architects must secure against external attacks and insider attacks. The approach is different for each threat. External attacks can be thwarted with strong whitelisting and using advanced authentication. Two- and three-factor authentication is not enough. Airtight multi-factor requires validating both people and machines over and above the “something known,” “something physically possessed,” and “something unique” that the industry typically uses today. MerlinCryption also employs “something temporary,” which increases authentication to 10 and more factors. All authentication data (both inbound and outbound) needs to be strongly encrypted.
Sophisticated internal espionage may overcome typical two-factor authentication. Again, the use of additional factors and something temporary fortifies prevention. A stealthy security system against insider attacks must encompass data-at-rest, data-in-motion, data-in-use and data-in-change. Real-time data change can be protected with an encrypted in-memory solution. Monitoring and recording activity helps identify the source of foul play. Using strong encryption, with larger variable-length keys, derails system compromise.
What characteristics would you suggest to look for when selecting a solid IPS security solution?
An airtight security process must not only deny access, but also secure data integrity while alerting operators of foul play. Instead of requiring every smart grid node to be capable of detecting intrusion, it is recommended to use multi-factor time-varying authentication and strong encryption with larger, variable-length keys. Keys that require no transfer are most advantageous. Additionally, it is an optimal strategy to have a separate system, which monitors for and reports intrusions on the smart grid networks
Built-in whitelisting can enable which code is allowed to communicate or cause critical actions. This security measure not only prevents but also alerts of an attempted violation of the whitelist.
We are putting billions of networked applications out with little concern for security. Where is the vendor disconnect in these security needs?
Before the recent outcry, security was often regarded as merely a nice feature. However, with the $388 billion cybercrime business now as large as the international illegal drug trade, and threats of foreign espionage, encryption is no longer a choice. Today’s environment requires that developers and OEMs strategically address the use of strong encryption and multi-factor time-varying authentication in the design phase of any project. A good security system must encompass data-at-rest, data-in-motion, data-in-use and data-in-change.
Are compliance, mandates and executive orders helping cyber security?
Compliance and security are not the same. Compliance sets a minimum standard. A system can be in full compliance and still be totally at risk. The concept of “minimum standard" is an open-ended problem, which evolves along with the evolving sophistication of the attacks. Mandates and executive orders are often “too little, too late.” Systems and their architecture must be proactively designed to address future attacks.
What needs to be done today to expedite readied security technologies in support of sensitive areas such as critical infrastructure?
Protecting access to status, states, reports, machine software updates, commands and controls is paramount to critical infrastructure security. These systems have unique high-risk challenges in different network zones, automated processes and device networks, including servers, human-machine interface (HMI), intelligent electronic devices (IED), controller logic, and industrial network protocols. Adequately securing critical infrastructure requires a dynamic encryption engine, which works in tandem with strong authentication.
As example, a man-in-the-middle strives to intercept messages, change updates, block alerts, or other false data injection between meters and the utility company. This type of attack against the grid would require authentication and encryption to securely, dynamically and flexibly transmit status messages, alarms and alerts between operators, security intelligence and machines in a sub-second response. The smart-grid operator needs the flexibility to continually change all key, password and authentication parameters, on command.
Protection of our critical infrastructure is a serious and immediate challenge for security leaders, striving to thwart potential incidents. Fortunately, the new ASBE encryption technology overcomes the obstacles of older encryptions and supports a national move to dependable security.
How can manufacturers prepare for new security requirements?
It is imperative that all systems, old and new, have more memory than currently needed, both RAM and Flash. This is needed for new functionality, evolving security threats, monitoring and alerts, and perhaps things yet to be thought of.
Two simple last questions: Why is security being breached today and has your solution ever been breached?
In today’s power-grid environment, we are connecting things that were never connected before, and they were never meant to be connected to the Internet. We are also working with old security architectures that can’t scale to today’s needs. These archaic systems do not address the complexity of SCADA control systems, and many were not built for network conductivity. The old ways won’t work. Critical infrastructure security needs a fresh look.
To answer your second question, the MerlinCryption solution has been pen-tested by the best -- including some noted hackers in Ukraine and Russia. ASBE encryption has never been broken. Encryption keys that disappear after they are used can’t be compromised. It doesn't have to be complicated. It is a matter of using common sense.
Larry Karisny is the director of Project Safety.org, a smart-grid security consultant, writer and industry speaker focusing on security solutions for the smart grid and critical infrastructure.
This Digital Communities white paper highlights discussions with IT officials in four counties that have adopted shared services models. Our aim was to learn about the obstacles these governments have faced when it comes to shared services and what it takes to overcome those roadblocks. We also spoke with several members of the IT industry who have thought long and hard about these issues. The paper offers some best practices for shared government-to-government services, but also points out challenges that government and industry still must overcome before this model gains widespread adoption.
Don't miss this opportunity to see the latest in digital government solutions, keep abreast of current policy issues and network with key government executives, technologists and industry specialists.
woah there.. i take issue with some thing here, and I think you may have been fallen victim to a press release.. "DES, RSA, SSL and AES algorithms produce simple key strands, which continually repeat in cyphertext." this flatly isnt true.. no good (commonly respected) cipher will leak key bits as you mentioned here.. what you said is true when your talking about a made up crypto scheme such as "xor".. but if you know how to extract key bits from an AES256 cipher stream i know a few governments who would like to make you rich.. speaking of made up crypto.. when i checked up on ASBE all i found documenting the encryption scheme was a PRWEB press release.. there was a wikipedia entry but it has been marked for deletion.. please folks.. if your looking to secure our critical infrastructure only rely on well vetted and public crypto.. if the scheme is proprietary pass.. if they cant tell you where they got the crypto library pass. if they cant point to third party studies of their ciphers strength pass.. if you need help choosing a reasonable cipher please contact your friendly local security consultant....(if your security consultant cant code.. pass)
The phrase "key stands, which continually repeat in cyphertext" means that the key is used in a periodic manner, as described in those encryption algorithms. DES is totally broken (see wikipedia), and even NIST says not to use it anymore. SSL has been broken many ways - if you want the links I can send them, but first ask "Palo Alto Networks" how easily they break SSL for their customers to make sure no one is sending company private data using SLL. AES is over 70% totally cracked like DES is 100% cracked. I can send you those links too if u r interested. And I suppose all of NSA's best encryption algorithms are published for your perusal?
Prem, I'm still not sure your being clear with your facts.. "DES is totally broken (see wikipedia)", yep.. no question.. but thats a weird thing to say since DES has long since been retired.. 3DES was its successor and it too is broken.. but I dont think anyone would recommend using it except in extremely old legacy systems.. "AES is over 70% totally cracked".. are you high? AES(128) has well known issues as it has been exposed to cryptanalysis.. there are attacks, and weaknesses.. but its not broken.. not even as bad as MD5 is broken.. and even then AES256 is already its successor.. it is not broken and claims to the contrary are misrepresenting the current state of cryptography. "but first ask \"Palo Alto Networks\"" to correct you on how palo altos product works, i will quote their product website: " A man-in-the-middle approach is used where device certificates are installed in the user's browser. By default, SSL decryption is disabled." ... so..you have to install the palo alto certificate before the palo alto device can decrypt traffic.. this is not SSL being "broken".. this is SSL being abused by palo alto to allow snooping.. "And I suppose all of NSA's best encryption algorithms are published for your perusal?" as a matter of fact, yes. Since DES (at the know known as lucifer) the NSA has publicly shared and recommended specific ciphers like AES (at the time known as "rijndael"), and currently the NSA calls the program "suite-b": http://www.nsa.gov/ia/programs/suiteb_cryptography/ again I would discourage anyone reading this article or this comment thread to discuss your cryptographic choices with a qualified security consultant and if your crypto isn't peer reviewed.. dont use it.
Mike, It was suite-a I was referring to for your perusal. My algorithm has been reviewed by NSA - this was in fact required to get our export license. Their feedback (not publicly available so doubt it if you wish) in a phone message passed on to me via and engineer at BIS is: We are restricted to not sell source code because if it fell in the wrong hands variations would be too hard to for them to crack. Also, we are restricted to not sell even binary versions to anyone the five listed terrorist countries or to any one who matches the OFAC list.
This encryption system has not been subjected to peer review and should not be considered safe for any purpose! The NSA does not endorse systems, they only review for export licenses. Your system will fail if the entire conversation is captured by an adversary. I would suggest reading past the first chapter of your encryption text book - your threat model is only appropriate for single-letter substitution ciphers like the kind used hundreds of years ago. Even the NSA uses peer-reviewed encryption algorithms, because only peer-reviewed alogorithms can be considered anything better than "security through obscurity". Every single fact you've mentioned is either trivially disprovable or indicates a complete lack of knowledge of what the actual threat models are. ATTN ALL READERS: You would be well advised to avoid this snake oil.
this comment board keeps eating my responses, so many things to say.. this time i'll keep it short, prem.. your secret "algorithm" has been revealed, i downloaded and decompiled (because you wrote it in .Net) your "merlinreader". i believe your crypto scheme to be flawed, one of the most obvious flaws you have is the use of a 16 bit LFSR which incorporates key bits into its seed values. source code follows: namespace WindowsFormsApplication1 { internal class Rand { public int r_now; private int r_mult; private int r_add; public Rand(int mult, int add) { this.r_now = 0; this.r_mult = mult; this.r_add = add; } private static int rand_flip_bits(int u) { for (int index = 0; index < 16; index) { int num1 = u >> index & 1; u &= ~(1 << index); int num2 = u >> 31 - index & 1; u &= ~(1 << 31 - index); u |= num2 << index; u |= num1 << 31 - index; } return u; } public ushort rand16() { this.r_now = this.r_add; this.r_now *= this.r_mult; int num = Rand.rand_flip_bits(this.r_now); this.r_now = (num >> 8 ^ this.r_now) & (int) byte.MaxValue | (this.r_now >> 8 ^ this.r_now) & 65280 | (this.r_now >> 8 ^ this.r_now) & 16711680 | (int) ((long) (num << 24 ^ this.r_now) & 4278190080L); return (ushort) (this.r_now >> 8 & (int) ushort.MaxValue); } } }
heres the high level of the crypto routine where the prngs are seeded *before* key expansion: this.mer_key_xfrm(); this.mer_spin_gen(); this.mer_rand1.r_now = (int) this.mer_key[0] | (int) this.mer_key[1] << 8 | (int) this.mer_key[2] << 16 | (int) this.mer_key[3] << 24; this.mer_rand2.r_now = (int) this.mer_key[12] | (int) this.mer_key[13] << 8 | (int) this.mer_key[14] << 16 | (int) this.mer_key[15] << 24; this.mer_rand3.r_now = this.mer_won.Millisecond * Process.GetCurrentProcess().Id; this.mer_key_expand(); and heres the key expansion function: private void mer_key_expand() { int index = this.mer_key_size; int num = 0; while (num < this.mer_key_step) { this.mer_key[index] = (byte) ((uint) this.mer_key[index - 1] ^ (uint) this.mer_rand2.rand16()); if ((int) this.mer_key[index] == 0) { this.mer_key[index] = this.mer_unique_id[this.mer_pnext]; if (--this.mer_pnext < 0) this.mer_pnext = this.mer_uid_len - 1; } num; index; } this.mer_key_size = this.mer_key_step; } shall i go on?
so others can review the security of the encryption algorithm implemented in merlinreader i have reimplemented it in python and have posted it here..: http://pastebin.com/AY2Ku1Pr its not complete but its readable friends don't let friends do security by obscurity!
Thanks Mike. I would appreciate any sincere reviews.
My sincere opinion/review is that this is another case of snake-oil cryptography.. if a client were to ask me about it i would advise them to steer clear of it or to use a cipher that takes longer to crack (even DES is designed better then this). I would also like to point out that when i went to download your challenge encrypted file I discovered that you attempted to block me from accessing your website (403 based on IP). I don't know if prem and his company are truely this naive in that they clearly dont appear understand the current state of cryptography or best practices or if merlincryption as a company knows full well that its products do not provide the protection they claim it does; whatever the case, this is a classic example of why you should never use cryptography without knowing whats under the hood.. and even then you need to make sure that whats there is implemented correctly. lastly merlincryption continues to make a claim about "NSA reviewed" and "BIS approved" as though this somehow is a testament to the encryptions strength.. but the security community /knows/ that BIS submission is something based entirely on key length and has nothing to do with the strength of the cipher.. and its approval for export generally means that its not considered "munitions" under the ITAR (as all strong encryption is). To put it another way,a childrens password protected journal using XOR encryption based on a passphrase could tout those very same claims if they considered what they were doing encryption and actually wasted the taxpayers money long enough to submit it to the NSA (if that even happened). if there is anyone currently using a merlincryption product that has a question i may be contacted @ioactive.com you can also mitigate this issue by upgrading your encryption: http://www.amazon.com/Girl-Tech-Password-Journal-Pink/dp/B0069S6M7C prem, i would ask that you taint something other then our national critical infrastructure with this nonsense.