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)