In her blog, Mary Ann Davidson, CSO at Oracle, is highlighting a weakness in the supply chain of software. She castigates US universities for not training software students in secure coding. She is awfully right, and it is not limited to US universities. Secure coding should be part of the normal programme of software development like methodologies, algorithmic and languages. Very few students have this secure coding background when joining the industry. Unfortunately, security becomes pervasive.

If students would have secure code lectures, this would not mean that they would become good at secure coding. It requires a given mindset (hacker minded?). Nevertheless, we could expect some benefits:

• Some elements of secure coding in their day to day work
• Avoid some basic errors in their production
• And most important, they would be security aware. They would ask knowledgeable people to put the right solution in place. They would avoid writing software with highways for hackers. They would be more robust against social engineering.

One of the challenges for teaching secure coding is that secure coding is not as advanced in formalization then other elements of software programming. Secure coding is very much based on heuristics and some pinches of black art. Academic communities should invest more in this field. More conferences should treat this topic. Furthermore, practitioners should teach in universities. Only real practical knowledge can generate secure code. Industry should help universities in this challenge.

She proposes also to have students hack each other solutions. This would be a revolution, but a good practice. It creates the right mindset. Hackers are used to that at conferences such as DefCon, Black Hat or Chaos Computer Camp. Even some governments experiment such challenges (See Défi Sécurité Système d’Exploitation Cloisonné et Sécurisé pour l’Internaute ). Should we not have such hacking challenges between universities?

I would like just to cite a dreadful statement, unfortunately true.
We simply – and collectively – must evolve to defensive mindsets delivering defensible code lest none of us survive in a hostile world.

Yesterday, I highlighted the focus on the chain of trust. I would like to come back to it.
Chain of trust is based on the concept that an authority is trusted. This authority then delegates its trust by signing a certificate to another authority. This is the way Public Key Infrastructures (PKI) do work. A Certification Authority has a root trust and all the certificates will cascade back to it.

In the case of downloaded/loaded software, it works in a similar way. The software to be downloaded is signed with the private key of an authority. The host, which should load the software, checks the signature using the corresponding certified public key. The certificate may be part of a hierarchical signature scheme. This seems extremely sound. Where is the problem?

From the cryptographic point of view, the trust model has mainly two assumptions (in addition to the traditional use of robust proven algorithms and secure implementation)
1- No private key involved in the signature schemes does leak. In reality, the assumption is mainly that the private root key does not leak. The other leakages can be coped through revocation.
2- The attacker cannot replace or add a new root public key.
The second assumption is often forgotten. Nevertheless, this seems still sound.

Unfortunately, the trust model is more complex. It adds a third assumption.
3- If a piece of software is signed, it means that this software is safe.

In an ideal world, assumption 3 means that the signing authority carefully checked the software and certifies that it is safe. Any developer knows how it is difficult to carefully review a small piece of software to find flaws, then reviewing the complete software…

In real world, if the host may receive many applications, for instance in game consoles, or future TPM based software for computers, we may assume that the signing authority will sign any piece of software presented by a software editor that it trusts. It means that the trust model has a fourth assumption:
4- A piece of software provided by a known software editor can be trusted.

Unfortunately, this assumption is rather weak. Many attacks or errors can invalidate it (malware insertion, security flaws, impersonation of the editor, …). It is why the chain of trust is not as efficient as we could expect in an environment that handles many applications.

The chain of trust may be stronger in more restricted environment such as Set Top Boxes.

In a recent post, at TechRepublic, Chad Perrin argued that open source is definitely a better security solution than proprietary solution because it complies with Kerckoffs Law.

Although, it is true most of the time, it is not an absolute truth in security (as usual). It depends on the trust model of the security system. I will take an example: OpenSSL. The trust model of SSL is that Alice and Bob trust each other and they want to avoid that Eve spies them or tampers their messages. Thus, OpenSSL uses cryptographic algorithms. The OpenSSL cryptographic toolbox is well studied and perfect. But only under the above mentioned trust model.

Let us now suppose that Alice wants to control the access of Bob to an information stored on Bob’s computer. She does not trust Bob. Thus, she will cipher the information with a secret key and gives a decryption program to Bob. Nevertheless, for obvious reasons, she wants to keep the secret key secret from Bob. She cannot use the cryptographic toolbox of OpenSSL (although it is good and has no flaws) because Bob, being a good hacker, will easily extract the secret key by knowing where and when it is used in OpenSSL.

This example is a simplified illustration of the problem of DRM. Therefore, it is impossible to design an open source DRM for B2C or B2B applications. The final user is not trusted. It may have sense in a C2C model (Consumer To Consumer).
Open source is perfect if the trust model of the system assumes that the “owner” or “operator” of the corresponding software is trusted. If it is not the case, then Open source is not the right answer. Then, we enter in the realm of secure coding and tamper resistant software which is another story.

Nevertheless, even for proprietary implementations, it is recommended to use well known and studied algorithms and protocols. Here, security by obscurity is bad. For implementation issues, it is another story (remember AACS hack)