Aug 14 2016

Law 3 – No Security Through Obscurity

This is the third post in a series of ten posts. The previous post analyzed Law 2: Know the Assets to Protect.

Undoubtedly, this law is one of the most famous laws of security. Unfortunately, its interpretation is too often over simplified. This law is rooted in the 19th century. In his “la cryptographie militaire”, Auguste Kerckhoffs, a Dutch cryptographer, stated: “A [cryptographic system] must require secrecy, and should not create problems should it fall into the enemy’s hands.” In other words, the robustness of a cryptographic system should rely on the secrecy of its keys rather than on the secrecy of its algorithm. As such, a strong assumption is that if an attacker knows the algorithm used, she should gain only a minimal advantage.

Prefer known published algorithms; a
design should only use known, published, cryptographic algorithms and protocols and avoid proprietary solutions. Most recent cryptosystems, such as AES or SHA3, have been selected through a public process with the extensive scrutiny of the cryptography community. Protocols such as PKCS and TLS are public and constantly examined. And regularly vulnerabilities are reported.

Protect the key; keys are the most valuable assets in cryptography. Key management is the most critical and complicated task when designing a secure system. The symmetric keys and private keys have to be protected by all possible means. Hardware vaults such as HSM, or smart cards require more effort to be penetrated than software-based vaults,

A very common misconception about Kerckhoffs’s law is that this law mandates publishing everything, including the source code of the implementation. The implementation details are dependent on the trust model. If the trust model is similar to the model of the following figure, then open source libraries are optimal.

Unfortunately, in some contexts, the trust model looks more like the following figure. Alice cannot trust Bob. Or even, if Alice can trust Bob, she cannot trust the system on which he runs. Ruth may have compromised the system. Digital Rights Management is an example of such hostile environment

In such configuration, open source libraries are not suitable. Indeed, the attacker knows exactly where and when the secrets are handled and thus can extract them without much effort. Under these conditions, proprietary implementations are preferable. In a hostile environment, the implementation should use obfuscation techniques or white-box cryptography.

Security should never rely exclusively on obscurity. Nevertheless, obscurity may be one component of the defense. However, whenever the secret or ruse obfuscated by the obscurity is disclosed, the system should remain secure. In other words, obscurity should not be the centerpiece of the security of any system.


Jul 06 2016

An insight in Knox

Samsung provides for its Galaxy devices an enterprise mobile security solution Knox. Among the features, Knox offers Workspace that compartments the mobile device in two spaces: user space and Knox space. Of course, the Knox space is running in a TrustZone™ and executes only authenticated trusted applications. There is not much public information about the actual implementation of Knox.

Uri Kanonov and Avishai Wool have lifted a part of the veil by reverse engineering Knox 1.0. Their paper provides an interesting in-depth description of some secure mechanisms such a compartmentalization (based on SELinux) or encryption file system. They also disclose some vulnerabilities. The last section describes some enhancements available in Knox 2.3 as well as some remaining issues.

An interesting element of the paper is the list of lessons:

  • Component reuse is welcome, provided a proper protection for the added attack surface.
  • Protect the software code of secure components
  • Validating the application authorized to run in the Trust Zone is key for security
  • Hardware Root of Trust should be at the root of any secure container system
  • Avoid resource sharing; it increases the attack surface.
  • Check the integrity of the secure container periodically; only checking at boot time is insufficient.

If you want to learn more about Knox, this paper is a good reading.

Kanonov, Uri, and Avishai Wool. “Secure Containers in Android: The Samsung KNOX Case Study.” arXiv, May 27, 2016.

May 24 2016

Law 2: Know the Assets to Protect

This is the second post of a series of ten posts. The first one analyzed Law 1: attackers will always find their way.

The primary goal of security is to protect. However, to protect what? “What are the assets to protect?” is the first question that every security analyst should answer before starting any design. Without a proper response, the resulting security mechanism may be inefficient. Unfortunately, answering it is tough.

The identification of the valuable assets will enable defining the ideal and most efficient security systems. The identification should specify the attributes of the asset that needs protection (confidentiality, integrity, anti-theft, availability, and so on). Assets are coming in many forms: human, physical goods, information goods, resources and intangible goods. The four first categories are often well treated. Unfortunately, it is not the case for the last one. Intangible goods are the intangible concepts that define the value of a company. They encompass notions such as brand, reputation, trust, fame, reliability, intellectual property and knowledge. For instance, a tarnished reputation may have serious business impacts.

Once the assets identified, the second step is to valuate them. All assets should not have the same value. For instance, all documents of your company are not to be classified as confidential. If you classify too many documents as confidential, users will become lax, and the mere notion of confidential will become diluted.

Once all the assets identified, it is time to make a threat analysis for the most valuable assets. It is not sufficient to know what to protect to design proper defense. For that purpose, it is key to identify the potential attackers. According to general Sun Tzu in his “Art of War”, it is paramount to know your opponents.

“If you know the enemy and know yourself, you need not fear the result of a hundred battles. If you know yourself but not the enemy, for every victory gained you will also suffer a defeat. If you know neither the enemy nor yourself, you will succumb in every battle.”

The knowledge of the enemies and their abilities is paramount to any successful security system. This knowledge can be collected by surveying the Darknet continuously, hacking forums and attending security conferences (Black Hat, Defcon, CCC, …). There are many available classifications for attackers. For instance,

  • IBM proposed three categories: clever outsiders who are often brilliant people, knowledgeable insiders who have specialized education and Funded organizations that can recruit teams of complementary world-class experts.
  • The Merdan Group defines an interesting five-scale classification: Simple manipulation, Casual hacking, Sophisticated hacking, University challenge and Criminal enterprise.
  • At CloudSec 2015, the FBI disclosed a motivation driven gradation: Hacktivism, Insider, Espionage, Terrorism and Warfare

The practitioner selects the classification that fits best the problem to analyze.

Once the threat analysis is completed, then starts the design of the countermeasures. An important heuristic to keep in mind: “in most cases, the cost of protection should not exceed the potential loss.” Usually, defense is sufficient if the cost of a successful attack is equivalent to or higher than the potential gain for the attacker. Similarly, defense is adequate if its expense is equal to or greater than the possible loss in the case of a successful attack.

Remember: know what you must ultimately protect and against who.

May 10 2016

A “charitable” ransomware

This is not a joke. Heimdal Security disclosed a new variant of ransomware combining CryptoWall 4 and CryptXX. It has all the usual components of ransomware. The ransom itself is high: five bitcoins (about $2,200). Usually, ransoms are around $500.

In addition to the exceptional price, the ransomware adds some social engineering tricks. In the ransom screen, you will find: Your money will be spent for the children charity. So that is mean that You will get a participation in this process too. Many children will receive presents and medical help!

And We trust that you are kind and honest person! Thank You very much! We wish You all the best! Your name will be in the main donors list and will stay in the charity history!

So do not hesitate to pay, it is for the kiddies L

Moreover, there is an additional benefit.

Also You will have a FREE tech support for solving any PC troubles for 3 years!

Trust us L

Remember the best practices for avoiding ransomware:

  • Backup your computer(s) regularly; Use a physical backup (air gaped) rather than a cloud-based one (unless it is disconnected). A new generation of ransomware also encrypts remote or cloud-based servers.
  • Do not be infected; do no click on suspicious attachments or links in emails; avoid ‘suspicious’ websites.
  • Protect your computer(s); up to date OS and antivirus

May 08 2016

Law 1 – Attackers Will Always Find Their Way

This is the first post of a series of ten posts. The order of the ten laws is not meaningful excepted for this first one. For three reasons:

  • It is the most important law as it is never failed. It should be engraved deeply in the mind of every security practitioner.
  • It is my favorite law. In 1996, when I founded the Thomson Security Laboratories, this law allowed us to enter into the Hollywood arena. We were the first to claim it systematically in front of the MPAA members. At this time, it was not obvious. In 1998, DVD John with DeCSS illustrated its pertinence. Studios started to listen to us. A side effect of the first law is that the world will always need good security practitioners. This is a reassuring effect. J
  • If somebody claim his or her system is unbreakable, then I already know that the system is snake oil.

No secure system is infallible. Any secure system is doomed to fail. Attackers will always find a way to defeat it. Even in ancient mythologies, it was true. For instance, invulnerable heroes such as Greek Achilles or Nordic Siegfried has a vulnerable spot. Along the History, this law has been right. Invincible Roman legions were defeated. Unsinkable RMS Titanic sank. Bletchley Park decrypted German Enigma. Mobile devices are jailbroken.

The only cryptographic system that has been demonstrated to be unbreakable in theory is Shannon’s One Time Pad. Unfortunately, it is not practicable. The symmetric key must be truly random and be of the same size that the clear text. Then, you have the problem to distribute the symmetric key securely, i.e., by secure sneaker net. Not very useful for everyday usage.

There is a strong asymmetry between security defenders and attackers. The attacker needs to succeed only once whereas the defender has to succeed every time. The attacker benefits from all the security technologies and tools that the defender may use. The attacker may put a lot of effort, resources and time for the exploit, as for instance, with high-profile Advanced Persistent Attacks (APT). Nature favors the attacker. The second law of thermodynamics states that entropy tends not to decrease. It highlights that it is easier to break a system than to build it. Creating increases the order, thus reduces entropy. Whereas breaking increases the chaos thus increases entropy. This is the sad, cruel reality of security.

Security designers must never deny the first law, but rather put this heuristic at the heart of their design.

The designer must expect the attackers to push the limits.
Any design operates within a set of limits defined by its initial requirements. The system should work correctly within these boundaries and should be tested within these limits. Unfortunately, an attacker may attempt to operate outside these boundaries to get unexpected behavior. The security designer should ensure either that these limits are out of reach or at least that the system should detect the violation of these boundaries to react accordingly. Typical examples are buffer overflows and SQL injections.

Systems will have vulnerabilities.
Publishing vulnerabilities is one of the best methods to reach a safer cyber world. Not only will the solution provider close the holes but the publication of the vulnerability will also educate the designers. Obscurity is dangerous for security (We will address it with Law 3). Nevertheless, implementers must have a reasonable amount of time to fix the issue before the public disclosure of the vulnerability. This is called responsible vulnerability disclosure.

As any system will be broken, the designed system must be ready to survive by the updating of its defense mechanisms. Without renewability, the system will be definitively dead. Renewability is a mandatory security requirement. The side effect is that the hacking scene must be monitored to learn as soon as possible about breaches and vulnerabilities.

As any defense will fail, a secure system should implement multiple defenses. Medieval builders knew about it. Middle Age castles had several bulwarks to protect the keep. Each one being increasingly higher than the previous one, It should construct successive obstacles that the attacker has to cross successfully. Diversity in protection makes the exploit harder to perform. A little ranting; one the current buzz messages of some vendors is “forget about firewalls and anti-viruses, use new method X”. Perimetric defense is of course not anymore sufficient to defend against modern threats. Nevertheless, the old-fashioned tools are still necessary for in-depth defense. Would you get rid of firewalls, then your network would become the weakest point of your system and would bypass new method X.

As any system will be broken one day, data may be corrupted or lost. Regular, frequent air-gapped backup of all non-constructible data is the ultimate defense. Back-up is today the only effective answer to ransomware (if you do not have a critical issue with data needed immediately, as for instance in hospitals). Air gapped is important to protect against a new generation of ransomware encrypting remote or cloud-based servers.

As a conclusion, never ask the question “if the system would be broken, …” but rather “Whenever the system WILL be broken, …”. The work of the security practitioner is to limit the risks of a breach, to detect its occurrence, and to mitigate the impact of such breach. The following laws will help in this difficult task.

May 02 2016

Is French HADOPI law dead (13)?

We know now for sure that HADOPI will be dead in 2022. On 27 April 2016, The French National Assembly approved an amendment that decrees that the HADOPI will expire on 4th February 2022.


Compléter cet article par l’alinéa suivant :

« II. – La même soussection est abrogée à compter du 4 février 2022. Par dérogation à l’article L. 33116 du même code, la durée du mandat des membres nommés après la publication de la présente loi expire le 4 février 2022. »


Comme le proposait le rapporteur en commission, cet amendement inscrit dans la loi la fin de vie de la Haute Autorité pour la diffusion des œuvres et la protection des droits sur internet (HADOPI) à compter de l’expiration du mandat en cours du dernier de ses membres nommés, soit le 4 février 2022.

It is a far milestone. Nevertheless, since a few months, HADOPI is in turmoil. In October 2015, the French Senate issued a report about the creation and management of the independent administrative authorities. The HADOPI is such authority. At page 70 of the report, the commissioner proposed to suppress the HADOPI as it has not proven its efficiency as the policeman of the Internet and that the graduated response is not operative to fight piracy.

Votre rapporteur propose ainsi la suppression de la Haute autorité pour la diffusion des œuvres et la protection des droits sur internet (HADOPI), considérant que cette autorité n’a pas apporté la preuve de son efficacité en tant que gendarme de l’internet et que les moyens de lutte contre le piratage à travers le mécanisme de la réponse graduée sont inopérants. En cas de réorientation de cet organisme, pour en faire un outil parmi d’autres de la lutte contre la contrefaçon culturelle et de la protection du droit des auteurs sur internet, il pourrait subsister sous forme de commission spécialisée voire d’établissement public.*

When will its actual death be?


* Therefore
your rapporteur proposes the deletion of the high authority for the dissemination of works and protection of rights on the internet (HADOPI), considering that this authority provided no proof of its efficiency as a Constable of the internet and the means of fighting piracy through graduated response mechanism are inoperative. If reorientation of this organization, to make one tool among others cultural counterfeiting and protection of the right of the authors on the internet, it could subsist in the form of commission or public institution. (draft translation from French to English)

Apr 22 2016

Shared Responsibilities on the Cloud

Microsoft recently published a paper titled “Shared Responsibilities For Cloud Computing.” The aim is to explain that when migrating to the cloud not everything relies on the lapses of the cloud provider to reach a secure deployment. This reality is too often forgotten by cloud customers. Too often, when assessing the security of systems, I hear the statement, but cloud provider X is Y-compliant. Unfortunately, even if this declaration is true, it is only valid for the parts that the cloud provider believes are under its responsibility.

The golden nugget of this document is this figure. It graphically highlights the distribution of responsibilities. Unfortunately, I think there is a missing row: Security of the Application executing in the cloud. If the application is poorly written and riddled with vulnerabilities, then game over. In the case, of SaaS, this security is the responsibility of the SaaS provider. For the other cases, it is the responsibility of the entity who designed the service/application.

The explanations in the core of the document are not extremely useful as many elements are advertising for Microsoft Azure (it is fair as it is a Microsoft document).

The document can be used to increase the awareness of the mandatory distribution and sharing of responsibilities.

Older posts «