Friday, November 26, 2004

Wednesday, November 24, 2004

No, Strong Names are NOT for code security :-(

Well, finally it seems to have dawned upon me that the .Net strong names are not really meant to secure your code. The last nail in the coffin was the revelation that one can easily tamper an assembly header to disable the strong name verification - without even removing the strong name! This effectively defeats the case of using strong names for cross referencing of assemblies based on strong names.

Read this thread:
Signed assemblies easily cracked?

Спасибо Valery and Danke Frank!

Sunday, November 21, 2004

Straight from the horse's mouth

If you have been made to think that the strong names are for code security - think again. They are best suited for versioning only.
Some more food for thought from Valery on strong names:
Valery's blog - Strong names are not security related thingies
Valery's blog - Strong names are not security related thingies (Story Continues)

Tuesday, November 16, 2004

Strong Names, what are they good for?

Recently Valery responded to one of my comments on the Microsoft's security newsgroup. It gave me a whole new perspective to think about on the concept of Strong Names and how useful they are:

Strong names are not security related! Stop relying on them for security
reasons and view them only for the purposes they were invented at the first
place - versioning. period.
There are plenty ways of stealing private key. Watching spreading rate of
malware and spyware suggests that stealing private key from personal
computer is trivial task at least on 90% of installed Windows base (refer to
the recent publications with claims* that at least 90% of Windows users have
spyware running on their computers). That will fall even to the script
If we go further - very few could actually handle their private keys good
(if you ask me - I can't handle my private keys). For handling private keys
well (like for example Verisign or Microsoft handles their pks) you would
need tempest protected hardware setup in highly electromagnetically isolated
location guarded with strong locks and live guards. Electromagnetic
radiation, processor heat, power consumption, operation timing and even
sound produced by processor - all that was shown to be able leaking private
keys to adversaries.
No system may be considered secure as long as it doesn't mitigate known
security threats. And strong names used for security reasons do nothing with
regards to key management and key revocation protocols. Leaving key
management and key revocation protocols for in-house implementation would
inevitably lead to security weaknesses.

[*] Even so I refer to 90%, but I believe that claim is quite questionable,
but even halving it to 45% still presents quite threatening picture.

P.S. I have several "strong names " related posts in my blog - if you
interesting you can simply search my blog for strong names.

Sunday, November 07, 2004

Compromising a strong name signed assembly

I saw this article on the CodeProject, which draws attention to the fact that simply signing an assembly by strong name doesn't guarantee that a hacker cannot turn it into a trojan horse :-( The author shows how easy it is to use the ildasm and ilasm tools to simply remove the publickey and hash algorithm segments from the assembly header in the IL code and recompile the IL code making the assembly unsigned!
Going one step further than that, the hacker could even sign the tampered assembly by his own private key - so potentially fooling the CLR, if the CLR grants trust to an assembly simply if it is signed.
I now more strongly feel that the onus is now on the system administator of the machine(s) to cleverly set trust and evidence based code access security policies for the CLR so that the compromised assemblies fail to execute. This can probably only be achieved if the policy is based on the publisher's identity - be it his public key or his digital certificate.