Questions
1. What is Microsoft’s smart card strategy?
2. Who is in the PC/SC Workgroup?
3. What has the PC/SC Workgroup provided? And when will it be available?
4. Are the OpenCard and JavaCard API announcements from the NC alliance competing with the PC/SC Workgroup?
5. Will these deliverables be made cross-platform?
6. When you say Windows components and tools, does this mean both 16 and 32-bit Windows?
7. Does Microsoft plan to support smart cards for Internet authentication and secure E-mail?
8. How does smart card logon work in Windows NT 5?
9. Will Microsoft support smart card logon on other platforms ?
10. Will Microsoft's smart card implementation work with the Java Card ?
11. How does the Microsoft Smart Card APIs compare with PKCS#11?
What is Microsoft’s smart card strategy?
Microsoft will ensure that the Microsoft® Windows® platform is smart card enabled for future electronic commerce and network security applications. This will allow smart card hardware and software vendors to develop products based on standard APIs and tools.
Microsoft’s initial implementation is focused on interoperability between cards, readers, and PCs. This will lead to a lower cost of deployment and maintenance of smart card solutions compared with non-PC based systems today. It will be easy and cost-effective for customers to take advantage of smart cards as part of a comprehensive security solution for the enterprise and the Internet.
Who is in the PC/SC Workgroup?
The Workgroup consists of leading PC and smart card companies including Bull CP8, Gemplus, Hewlett-Packard, IBM, Microsoft, Schlumberger, Siemens Nixdorf, Sun Microsystems, Toshiba, and Verifone.
What has the PC/SC Workgroup provided? And when will it be available?
The PC/SC Workgroup facilitated the development of smart card based applications for the PC by developing open specifications that ensure interoperability among smart cards, smart card readers, and computers made by different manufacturers. The group, which has been working together since May 1996, has published the specifications at http://www.smartcardsys.com/. Microsoft delivered a reference implementation for the Windows platform in the last quarter of 1997.
Specifically, the technology developed by the PC/SC Workgroup includes:
· A high-level applications interface to make it easier to build and maintain smart card applications
· Programming interfaces (that is, device drivers) for smart card reader peripherals connected to a PC
· Specifications for cryptographic functionality and secure storage to be provided by the smart card
Microsoft has implemented these specifications for the 32 bit Windows platforms.
Are the OpenCard and JavaCard API announcements from the NC alliance competing with the PC/SC Workgroup?
The JavaCard API announcement is complementary to the efforts of the PC/SC Workgroup, because it addresses the issue of how to rapidly deploy applications that run inside smart cards. The PC/SC Workgroup specifications are Java™-friendly at both the card and application levels. The JavaCard API announcement is not documenting new APIs to enable developers to integrate smart cards with PCs; it is documenting a subset of Java APIs for developing applications that will run on smart card hardware only. To have customer value, these applications will need to communicate with devices such as PCs through the readers, making the PC/SC Workgroup efforts very important and complementary to the JavaCard API announcement. Microsoft will be investigating how its technology and tools can add value to these efforts.
At the present time, there is not enough information about OpenCard to determine compatibility with PC/SC because the NC alliance has yet to release any specifications. The OpenCard has announced that their specifications will be compatible with the PC/SC specifications.
Will these deliverables be made cross-platform?
Using the specifications developed by the PC/SC Workgroup, reader OEMs can deliver smart card readers for any platform, and all operating systems vendors are encouraged to integrate support into their products. However, full integration with other platforms will require support from appropriate OS vendors. Microsoft has delivered the implementation for the 32 bit Windows platforms.
When you say Windows components and tools, does this mean both 16 and 32-bit Windows?
At this time, these components and tools will be for 32-bit Windows only. Microsoft will evaluate support for 16-bit Windows based on customer demand.
Does Microsoft plan to support smart cards for Internet authentication and secure E-mail?
Yes. Internet Explorer 4.0 and Outlook Express 4.0 and Outlook 98 fully support the use of smart cards for user authentication and secure S/MIME email today. This works with any smart card that supports RSA cryptographic operations and has a Cryptographic Service Provider (CSP). Readers and cards are available from the leading vendors that support IE and OE. (www.Microsoft.com/smartcard)
How does Smart Card log on work in Windows NT 5?
Windows NT 5 uses the PKINIT protocol for public key authentication (It is an extension to Kerberos v5 and is an IETF draft). This allows an authorized user to use a certificate (and associated private key) to insert their card in a reader, authenticate to the card and use the certificate/private key to authenticate to the Windows NT domain. Once the user is authenticated they get a Kerberos ticket and can use that ticket to access resources in the domain.
Will Microsoft support Smart Card login on other platforms ?
Smart Card login will only be supported on the Windows NT 5 platform.
Will Microsoft's Smart Card implementation work with the Java Card ?
Microsoft's smart card implementation is completely agnostic to the operating system on the card itself. It is designed to accommodate any card OS. Therefore it will work with the Java Card (or any other card) with the appropriate card service provider installed.
How does the Microsoft Smart Card APIs compare with PKCS#11?
The PC/SC specifications that have been implemented by Microsoft offer a more complete and full architecture that meets the broad goals of full interoperability . On the other hand, PKCS-11 is just an API and not an architecture. It is very narrow and not interoperable among different vendors.
· PKCS-11 fails to separate reader interfaces from hardware token interfaces. What this means is it doesn't provide a basis for allowing readers and smart cards from different vendors to interoperate.
· PKCS-11 is only an API spec, and doesn't define how one would support multiple devices in a system. It also does not define an exportable architecture.(Per US Govt. laws) The announced solution only works because they have restricted functionality to user authentication services, as opposed to full crypto services supported by CryptoAPI.
· PKCS-11 deals with slots and tokens. This corresponds almost exactly to the PC/SC concepts of readers and cards. However, PKCS-11 has a very fixed set of services that a token is allowed to perform (Data Storage, Certificate Storage, and Crypto Key operations), and a very rigid security model. The PC/SC model allows for unlimited functionality extensions through the use of service providers.
· Since there is no layered architecture, each vendor supporting PKCS-11 must provide a complete, and independent, library for accessing their hardware. There are absolutely no rules for how these libraries are registered (so that an app can select the one they want) and no rules for allocating 'slots'.
· PC/SC allows the selection of cards by capability. There is no such concept in PKCS-11.
· PKCS-11 does not support multiple applications accessing a single token simultaneously, and does not provide transaction or locking semantics. The PC/SC architecture does.
No comments:
Post a Comment