Friday, June 19, 2009
#
Like all good geeks as soon as a software update for one of my toys comes out I apply it, so when the 3.0 update for the iPhone came out I was right there.
I had hoped that it would resolve some issues I had been having with my phone, it did not, but Apple did replace the phone for me when I took it to them.
The problem is that when I had upgraded the phone (even before the hardware switch) my backup did not restore the applications I had on my phone, for the most part that was fine because they were still available; the thing is NetShare (a socks proxy to enable tethering with the phone) was not.
With that in mind I was left looking for an alternative, it’s not that I used it frequently but there have been times where that’s been supper useful.
Being a gadget hound I follow Engadget, they recently had a post about how to enable the native tethering support of iPhone 3.0; I followed the steps and viola, tethering showed up in the UI.
I paired the device with my Windows 7 machine and I saw a new device, but no driver was found; its HW ID was:
BTHENUM\{00000000-deca-fade-deca-deafdecacafe}_VID&000205ac_PID&1292.
Notice the strange service ID in the HW ID, (looks like someone needs to get a copy of GENGUID), in any event with some research on the web and some help from some folks I work with I discovered this is ID maps to something called “Wireless iAP” which is supposedly an Apple proprietary Bluetooth profile for a Wireless Internet Access Point.
The problem is that that there is no profile for this in Windows 7 and I have not been able to find a third-party profile I can load; I may get there, and if I do I will update this post but for now it looks like I may be out of luck.
I wonder why they did not use the standard profiles for this stuff, oh well.
[Update 6/22/09 11:00AM] I am a idiot, yes; turns out I did not have Tethering "ON" when I tried this; once I did that it worked just fine... 100% user error; just tried the connetion via speedtest.net and I was getting .60 down and .20 up.
This begs the question what is this "Wireless iAP" thing, its clearly not required for this scenario.
Wednesday, January 14, 2009
#
I will use this post to catalog public resources on the Windows Biometric Framework.
If you run across any that I miss please let me know, I should reliably catch the technical content ;)
TECHNICAL
EDITORIAL
Saturday, January 10, 2009
#
For security reasons the default setting in Windows is to prevent the the direct access to removable media over Remote Desktop sessions.
In my case I almost never use my main Media Center pc directly and instead I connect in using RDP, as a result this default causes me grief.
To change the setting all one needs to do is:
- Open GPEDIT.MSC
- Navigate to: “Local Computer Policy\Computer Configuration\Administrative Templates\System\Removable Storage Access”
- Find the “All Removable Storage: Allow direct access in remote sessions” option and enable it.
Now you can right click and eject the DVDs in Remote Desktop sessions.
Tuesday, December 30, 2008
#
Those watching the advances in crypto-analytics over the last couple years (since 2004 If I recall correctly) have had interesting ride, well as interesting as crypto-analytics is.
A group of researchers just published the 1st "practical" MD5 attack, they created a rouge CA certificate that matches that a trusted CA, read this for more information.
Some highlights of the attack include:
- Attacker was able to take advantage of CAs that uses predictable serial numbers that issues certificates within a predictable amount of time
- Attacker has full control of the first 500 bytes of the colliding certificate, which means they can generate a subordinate CA certificate with a serial number unknown to the commercial CA
- The attack generates RSA keys that can be used to produce valid signatures
- The amount of time needed to generate a RSA key pair that will produce a collision is around 3 days (using a cluster of 200 PlayStation 3 machines running Linux)
- Certificate revocation cannot be used as a mitigation, unless the key being attacked is associated subordinate and the issuer is willing to revoke that certificate (affecting all children, even the legitimate ones).
- This is not a 2nd order pre-image attack and does not affect previously issued certificates
This means that they can trivially mint certificates (or any other signed object) of their choosing's that will be accepted as trusted by any entity (most commonly browsers and certificates) that trusts this key.
It sounds as if they are being responsible researchers by withholding the details of their attack until the affected Certification Authorities have had some time to re-issue those certificates.
In the end though, this is really the death-knoll of MD5, its now officially no better than a CRC.
As an application and protocol developer I have always strived to make my designs crypto-agile and agnostic to accommodate for varying customer needs, later in life when I started to appreciate the life-cycle of a cryptographic algorithm I also started to attribute those design decisions to algorithm sunseting as well; the hard part though is not design, its the operational and legal implications of such a transition.
As I said, those watching things advance over the last few years should have been preparing for this, and hopefully have action plans in place or already executed mitigating the implication of the result of the attack in question; the longer term implications though require us to move away from MD5 and the algorithms that have similar properties to it (even SHA-1 even though currently its still generally considered safe)
This is why NIST has spun up the Hash Workshop, one of my co-workers, Niels Ferguson [warning PDF link] has a horse in the race with some of his fellow cryptographers, only time will tell how this will turn out.
Tuesday, December 23, 2008
#
We just recently published a new White Paper that provides a great Introduction to the Windows Biometric Framework.
Monday, December 08, 2008
#
Today my test lead let me snag one of the laptops we recently ordered for selfhost testing of some of our technologies.
My current laptop is a X61, only about a year old and its no slouch but boy this X301 is fast, and this screen its beautiful!
Its running a recent Windows 7 build and all I can say is WOW...
I am tempted to buy one for home use!
Saturday, December 06, 2008
#
One of the more common codec related problems people run into is the in-proper registration of the "PerceivedType" and "Content Type" for a container file format. Windows expects this to be done so it knows how to discover the codecs to be used with a particular file extension.
To that end a .reg file that registers the most common container file types with the appropriate settings would look as follows:
Windows Registry Editor Version 5.00
[HKEY_CLASSES_ROOT\.ogg]
"PerceivedType"="audio"
"Content Type"="audio/x-ogg"
[HKEY_CLASSES_ROOT\.ogm]
"PerceivedType"="video"
"Content Type"="video/x-ogg"
[HKEY_CLASSES_ROOT\.m2v]
"PerceivedType"="video"
"Content Type"="video/mpeg"
[HKEY_CLASSES_ROOT\.mka]
"PerceivedType"="audio"
"Content Type"="audio/x-matroska"
[HKEY_CLASSES_ROOT\.mkv]
"PerceivedType"="video"
"Content Type"="video/x-matroska"
[HKEY_CLASSES_ROOT\.mp4]
"PerceivedType"="video"
"Content Type"="video/mp4"
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Multimedia\WMPlayer\Extensions\.ogg]
"Runtime"=dword:00000007
"Permissions"=dword:0000000f
"UserApprovedOwning"="yes"
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Multimedia\WMPlayer\Extensions\.ogm]
"Runtime"=dword:00000007
"Permissions"=dword:0000000f
"UserApprovedOwning"="yes"
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Multimedia\WMPlayer\Extensions\.m2v]
"Runtime"=dword:00000007
"Permissions"=dword:0000000f
"UserApprovedOwning"="yes"
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Multimedia\WMPlayer\Extensions\.mka]
"Runtime"=dword:00000007
"Permissions"=dword:0000000f
"UserApprovedOwning"="yes"
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Multimedia\WMPlayer\Extensions\.mkv]
"Runtime"=dword:00000007
"Permissions"=dword:0000000f
"UserApprovedOwning"="yes"
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Multimedia\WMPlayer\Extensions\.mp4]
"Runtime"=dword:00000007
"Permissions"=dword:0000000f
"UserApprovedOwning"="yes"
Sunday, November 30, 2008
#
Plug-and-Play is a feature in Windows that enables the automatic self-configuring of devices.
When you plug a device into your PC and Windows knows the identity of the device and tries to retrieve the driver for the device, that is Plug-and-Play.
One of the smaller features in Windows that will likely never see any press is the support of Plug-and-Play with Smart cards.
Historically Smart cards have been tightly integrated with each application using libraries like PKCS #11 or Cryptographic Service Providers.
There are many problems with this approach, for one they seldom lead to true application interoperability, that is without a ton of scenario and application specific work on behalf of each and every application.
The main reason behind the need for the application specific work is the interface contracts for libraries like this are designed for generic cryptographic extensibility and not the narrow capabilities of a smart card.
In simple terms, a smart card can do a handful of things but one of these libraries must do dozens if not hundred of things.
In the Windows XP SP2 timeframe Microsoft introduced a new provider model for Smart Cards was, its was called a Smart Card Mini driver; support for this concept was made available for Windows 2000 and up platforms via a downloadable package.
In this model smart cards vendors only need to expose the minimal set of things the card can actually do in their middleware, the rest of the work necessary to work well in applications is handled by a higher-layer.
In the Windows VISTA time-frame a certification test-suite was also provided, with this suite vendors could test their cards to get an idea if they would work in common Windows scenarios and ensure they meet a basic quality bar.
As a result of completing that test suite successfully vendors can include the "Designed for.." logo's on their marketing materials and distribute the drivers via Windows Update.
Windows 7 builds on this by being able to automatically detect which drivers are appropriate for a given smart card and install them (with no user interaction!).
For users most users this means when they insert their smart cards they "just work", if they pay close attention when they insert a smart card during a interactive session they will see a bubble:
If they click on that bubble they will see the "Driver Software Installation" dialog, beginning searching for device drivers:
This dialog will change to show the driver was installed:
From that point on when the card is inserted the right driver will be automatically loaded for the device, when the user goes into Device Manager they will see a new Smart Cards node:
Another side affect of this is that Smart cards now can take advantage of the improved driver installation facilities in Windows 7, this means that Smart card drivers can be installed before there is a interactive session and by standard (non-administrative) users.
This feature is important for a number of reasons, one of which is that the number one complaint for Smart card deployments is the need to deploy complex proprietary middleware to use them.
A variation on that middleware deployment problem is relation to National ID cards, its one thing for a enterprise to need to deploy middleware for a smart card its another entirely for a government who wants to use smart cards for citizen to government commerce, now for Windows 7 they have a solution to that problem.
Saturday, November 29, 2008
#
I ran across a neat article on using Javascript and default CSS behaviors to infer what sites you frequent, this is not new, the earliest reference I could find of this was from 2006 but I bet this has been going on for much longer.
An example of analytics that can be applied to this data is that one follow is using your URL history to infer gender.
These are great examples of thinking outside the box and how privacy is an illusion (especially on the web).
I just posted "How to convert a HD-DVD to an AVI" this was the winner in my various experiments to get HD-DVD content to work so I can shelf the drive since I will not be able to get new content on this media format.
All of the goals and caveats of that post apply here as-well, the first steps are the same, the last steps are the only ones that change.
- Demux the HD-DVD into its elementary streams using EVODMUX.
- Convert the VC-1 elementary stream from the HD-DVD 29.97 fps streams with pulldown flags to 23.976 fps progressive using vc1conv.
- Transcode the DD+ audio stream to regular AC3 using eac3to.
- Remux the VC-1 elementary stream and the AC3 stream into a M2TS (AVCHD) or TS using TSMuxR.
The resulting file was playable with ffmpeg\ffplay, I could also import this file with Handbrake (who by the way is a great tool, but don't ever venture into their forums the authors are hostile at best).
I suspect with additional codecs it would have played in WMP and Media Center also but I really did not want to need additional codecs for this to all work.