Attempting to debug my webservice from VS.NET, and I’m getting this message, eventually I track it down the the VDIR ASP.NET setting for the version of .NET to load.
Having recently installed .NET 2.0, it must have changed the default, since my ASP.NET application was trying to load .NET 2.0 for my 1.1 Webservice.
I change it back to 1.1, and all is well with the world once more.
A while back I posted a blog about [my opinion of] the supposed weakness’s of the UK ID Card scheme – looks like I was mostly right.
The precursor to ID Cards are RFID enabled passports – these are passports containing an RFID chip which contains “information”, and we can suppose in the future will contain some kind of biometric component. These passports can be read electronically using contactless reading devices – so in theory all you have to do is wave the passport near the reader for the passport data to be read.
Well, these shiny new passports have arrived, although at the moment they don’t contain any biometric information, the passport office says they contain only information which is also printed within the passport document.
The bad news is they’ve already been cracked – and it wasn’t that difficult or expensive apparently, read this article for the full details.
The problem is a simple and fundamental mistake, no one involved in IT security would make – which kind of says that this system was cobbled together in the “design by committee” fashion, one would presume by highly paid “consultants” who know nothing about designing secure systems.
Anyway I digress, the problem is that the information contained on the RFID chip, is not encrypted. While this sounds bad, it isn’t neccsarily, because the chip won’t yield up it’s information without the reader establishing a secure conversation with the chip first. Part of this process involves the reader providing an key with which the reader <-> chip communication is encrypted – and the key is derived from clear text information printed on the passport;
I.e passport number, date of birth and expiry date
Oh dear, but then they proudly exclaim that they are using military grade encryption, so thats alright then? Well actually no, they’re using 3DES, while it’s pretty strong, if you’re designing a new secure system why not use a modern, cryptograhpic cipher with proven [by real life honest to goodness actual cryptographers] strength like AES.
It gets worse, Passport office spokes persons actually start to counter these citicisms with missives beginning with statements such as “…This doesn’t matter, by the time you have accessed the information on the chip, you have already seen it on the passport……..If you were a criminal, you might as well just steal a passport”. This just highlights their naivety and doesn’t bode well for the future of biometric passports, especially given the governments track record on implementing any kind of IT system.
Yeah, I nearly forgot, given that the key source material is in the clear, you could argue that an attacker needs sight of the passport to get the passport number, DOB and expiry date, from which to derive the key.
Not so, consider the dodgy postman scenario, or come to that the dodgy passport agency employee, or indeed anyone who comes into contacts with passports before they are dispatched;
The expiry date is known to be 10 years hence from when it is delivered give or take a day or 2, the DOB is readily available information, but the passport number is only 9 digits long, roughly a set of 3.5 trillion numbers, so it’s subject to brute force attacks, which is unfortunate, because the RFID chip offers no defence against brute force attacks, nothing not even a limited number of key authentication attempts before the chip locks for a period of time. WTF, even when you enter you PIN in an ATM machine you only get 3 or so attempts – what were they thinking?
So what does this all mean?
Whats a person to do, since we’re all going to be forced to take an ID card at some point – well, if you apply for an RFID passport now, you won’t be obliged to take an ID card untill that passport expires, which is currently 10 years. So at least if you do this, you can be sure that your passport doesn’t contain any real personal data for the next 10 years before you have to take on an ID card.
Oh yes, having got your RFID passport, when you carry it around, wrap it in tin foil, this will prevent it being read at a distance without your knowledge.
The full article can be found here [http://www.guardian.co.uk/idcards/story/0,,1950226,00.html]
Trawling the t’internet late last night I turned up this little MSDN nugget which explains the situation, see paragraph 5 in the Deployment section of the full article.
“Since the configuration data for services on managed classes are stored in the COM+ catalog, certain catalog entries may also be modified administratively after registering an assembly. Some services should not be modified in this manner. For instance, disabling the transaction service in the catalog can cause the code to operate incorrectly. Deployment-specific settings like object construction strings and security roles can be manipulated post registration. XCopy deployment of assemblies containing serviced components may not be sufficient when post registration settings are made. The COM+ application import and export feature helps to distribute the current state of the application. Further information about import and export is provided in the remoting section.
In some cases the catalog is not consulted for configuration data but is extracted purely from the assembly metadata. The cases are for AutoComplete, JIT, Object pooling (although the pool size is extracted from the catalog) and the secure method attribute. More details about this issue are discussed in the sections describing those services.“
The full article can be found at;
Understanding Enterprise Services (COM+) in .NET
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndotnet/html/entserv.asp
I have a C# component attributed with COM+ configuration settings, one of which is ObjectPooling – set to disabled. The object overrides Dispose and ServicedComponent Activate, Deactivate and CanBePooled methods, CanBePooled always returns true. The component is registered in a COM+ server app using RegSvcs. I run up my unmanaged C++ test app and observe the object activation sequence I expect (all methods have trace messages);
So far so good, CanBePooled is not called and the object is not shown to be pooled in CSE.
I shutdown the COM+ app and set the components ObjectPooling to enabled using the CSE. I then re-run the test app, and see the same activation sequence – CanBePooled is not called and the object is not added to the pool (as seen in CSE) – this isn’t right!.
I shutdown the COM+ app, and modify the component source code to enable the ObjectPooling attribute, rebuild and re-register with RegSvcs (with /reconfig switch). I run the test app and now see the activation sequence I expect;
CanBePooled is called and the object is shown to be pooled in CSE.
This is the weird bit - since the object is using JIT – the COM+ context, TP and SCP remain active independently of the real object, the interception services configured for the COM+ context and therefore involving the SCP / TP / Real Object interactions don’t seem to be working independently of the objects meta-data, as though they are ignoring the services configuration held in the COM+ catalog for the component.
If anyone can shed any light on this I’d appreciate it very much as my head is starting to dent the desk .
RSS - Posts
My 