WO2003040869A2 - Authentification d'utilisateur/produit et systeme de gestion de piratage - Google Patents

Authentification d'utilisateur/produit et systeme de gestion de piratage Download PDF

Info

Publication number
WO2003040869A2
WO2003040869A2 PCT/US2002/032292 US0232292W WO03040869A2 WO 2003040869 A2 WO2003040869 A2 WO 2003040869A2 US 0232292 W US0232292 W US 0232292W WO 03040869 A2 WO03040869 A2 WO 03040869A2
Authority
WO
WIPO (PCT)
Prior art keywords
user
authentication
software
access
external source
Prior art date
Application number
PCT/US2002/032292
Other languages
English (en)
Other versions
WO2003040869A3 (fr
Inventor
Balamani S. Vishwanath
Brian D. Mantz
Original Assignee
Smarte Solutions, Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Smarte Solutions, Inc. filed Critical Smarte Solutions, Inc.
Priority to AU2002347849A priority Critical patent/AU2002347849A1/en
Publication of WO2003040869A2 publication Critical patent/WO2003040869A2/fr
Publication of WO2003040869A3 publication Critical patent/WO2003040869A3/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/10—Protecting distributed programs or content, e.g. vending or licensing of copyrighted material ; Digital rights management [DRM]
    • G06F21/12—Protecting executable software
    • G06F21/121—Restricting unauthorised execution of programs
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31—User authentication
    • G06F21/34—User authentication involving the use of external additional devices, e.g. dongles or smart cards

Definitions

  • the system relates to multiple facets of Sources desiring additional system user authentication and security or product authentication and anti-piracy management tools or applications.
  • Passwords and simple one-factor authentication models do not positively identify a user, provide an audit trail of user activity, or provide user accountability.
  • a powerful physical authentication mechanism that uniquely, conveniently, and cost effectively provides true user identification and non-repudiation while providing an optional platform for a single universal loginpassword to allow user access to multiple accounts will set a daunting precedent in the online arena.
  • a separate, but related issue to that of enterprise software access management is that of enterprise software installation management.
  • Installation agreement enforcement is essentially relegated to the enterprise software purchaser on a 'good faith' basis.
  • the larger and more diverse an enterprise is generally correlates with higher rates of installation mismanagement.
  • many instances of enterprise installation abuse are, indeed, intentional, a significant number result simply from unintentional oversights. Therefore, an effective method to manage application use with respect to defined license agreements would not only benefit the software manufacturer, but the enterprise customer wishing to comply with those license agreements.
  • o Piracy expands company, brand, and specific product user bases.
  • o Piracy acts as a strong marketing vehicle, significantly extending the exposure of the company, brand, and product, o Piracy can serve to provide 'trial' versions to potential and future legitimate purchasers.
  • Piracy is a global multi-billion dollar issue for software manufacturers of all types. As pirated products directly and indirectly lead to as much as 80% of legitimate sales in particular market segments, the desire on the part of the industry is to manage the issue to its economic advantage. Altogether or virtually eliminating the issue would only serve to eliminate extended product user bases and, hence, a substantial source of revenue.
  • the present invention is a software solution that provides new and unique solutions to the problems previously described. It does this through innovative and new forms of strong user identity as well as software piracy management. These items are listed as follows:
  • the present invention offers a two-factor authentication service combines "something the user knows", a username and password, with "something the user has”, to form a device preferably referred to as a Smarte DeviceTM.
  • authentication preferably referred to as Smarte AuthenticationTM
  • Smarte AuthenticationTM greatly reduces the potential for and costs associated with identity fraud by establishing strong user accountability (true user non-repudiation) and by generating an audit trail of user activity.
  • Smarte AuthenticationTM is an integrated security component of the pay, preferably referred to as Smarte PayTM, infrastructure which efficiently overcomes the failings of one-factor, password-only authentication systems.
  • the present invention accomplishes strong two-factor digital authentication through the use of highly portable and easy to use Smarte DevicesTM.
  • Smarte DevicesTM include software tokens that reside on handheld PDAs or WAP enabled cell phones, key chain tokens that generate a new authentication code every few seconds, and identification, preferably referred to as Smarte IDTMs - unique authentication devices that may be developed and produced in-house. Smarte DevicesTM offer strong branding opportunities for partners and clients using Smarte AuthenticationTM. The Smarte IDTM itself is offered in two formats: as a wallet-sized CD or as a Smart Card. Using encrypted digital algorithms capable of being read by any type of CD drive or Smart Card Reader, the Smarte IDTM provides the convenient functionality of alternative two- factor authentication devices, but at a fraction of the cost.
  • Smarte AuthenticationTM is structured/designed so that it can act as a stand-alone digital authentication service for third parties independent of the functions of the Smarte Pay infrastructure.
  • the Smarte ID (CD format) also provides product authentication to software manufacturers by preventing the unauthorized use of a product sold on the CD (anti-piracy solution).
  • FIG. 1 is a flowchart of primary system entity relationships
  • FIG. 2 depicts basic relationship between Authentication devices, External Sources, and Lots
  • FIG. 3 depicts basic system relationships of External Source's their system users and devices
  • FIG. 4 depicts basic system relationships regarding system Access Authorizations
  • FIG. 5 depicts the basic system relationships regarding Product Authentication
  • FIG. 6 depicts the placement of the Screen Identification Code (GUI) for Authentication Screens
  • FIG. 7 depicts Authentication Management Screen Layout for Admin Users
  • FIG. 8 depicts Authentication Management Screen Layout for External Source Users
  • FIG. 9 depicts Screen Layout for Authentication End Users
  • FIG. 10 depicts the System Data Structure Layout and record relationships within the system
  • FIG. 11 is a table containing the Table Names referenced in FIG. 10;
  • FIG. 12 is a visual representation of the Smarte CDTM Authentication Device
  • FIG. 13 is a visual representation of the Smart Card Authentication Device
  • FIG. 14 is a visual representation of the RSATM SecurlDTM Authentication Device
  • FIG. 15 is a flow chart of the Smarte AuthenticationTM plug-in operational and communication flow for Type I Authentication use
  • FIG. 16 is a flow chart of the Smarte AuthenticationTM plug-in operational and communication flow for Type II Authentication use
  • FIG. 17 depicts the basic flow of Authentication Responses based on implementation
  • FIG. 18 depicts the basic flow of Authentication Responses based on implementation in addition to those depicted in FIG 17;
  • FIG. 19 depicts Authentication Plug-in Information Passing Requirements
  • FIG. 20 is a flow chart of the Smarte AuthenticationTM system operational and communication flow for Product Authentication use
  • FIG. 21 is a flow chart depicting the specific Authorization process for Smarte CD T Devices
  • FIG. 22 is a flow chart depicting the specific Authorization process for Smart Card Devices
  • FIG. 23 is a flow chart depicting the specific Authorization process for 3 rd party Devices.
  • FIG. 24 is a flowchart depicting the basic flow of the Smarte Authentication device/authorization process
  • FIG. 25 depicts a typical Security Arrangement for hardware/software for 3 rd party Authentication Processes, using the system as a portal only;
  • FIG. 26 depicts diagram displaying the Extended DLL data file structure
  • FIG. 27 is a flow chart depicting the basic functional flow of the Standard DLL
  • FIG. 28 is a flow chart depicting the basic functional flow of the Extended DLL
  • FIG. 29 is a flow chart depicting the Validate Device function of the Extended DLL
  • FIG. 30 is a flow chart depicting the Extended DLL Validate Device to Serial Number function
  • FIG. 31 is a flow chart depicting the Extended DLL Add User ID function
  • FIG. 32 is a flow chart depicting the Extended DLL Kill User ID function
  • FIG. 33 is a flow chart depicting the Extended DLL Assign Device function
  • FIG. 34 is a flow chart depicting the Extended DLL Unassign and Kill Device functions
  • FIG. 35 is a flow chart depicting the Extended DLL Validate User function
  • FIG. 36 is a flow chart depicting the Extended DLL Validate User ID Exists in System function
  • FIG. 37 is a flow chart depicting the Extended DLL Return Device Info for User ID function
  • FIG. 38 is a flow chart depicting the Extended DLL Identify User ID and Return Device Info functions
  • FIG. 39 is a flow chart depicting the Extended DLL Import Device Info function
  • FIG. 40 is a flow chart depicting the Extended DLL Initiate Datafile, Lock Datafile, Unlock Datafile, and Change Locked Datafile Password functions
  • FIG. 41 is a flow chart depicting the function of the replication/duplication management software for non-serialized CD-ROMs only containing the media-based copy protection;
  • FIG. 42 is a flow chart depicting the function of the replication/duplication management software for serialized single set CD-ROMs
  • FIG. 43 is a flow chart depicting the function of the replication/duplication management software for serialized sets of CD-ROMs.
  • FIG. 44 is an overview diagram depicting plug-in inter-system relationships.
  • Inventory is where information for all devices utilizing the Smarte Authentication System is initially stored prior to issue/use.
  • the System's dual authentication procedure is predicated on the use of devices (hard/soft) to verify the true identity of any user.
  • the System has been developed to recognize these Smarte IDs during the authentication of a user. Smarte ID Distribution Process
  • the present invention has defined multiple device distribution methodologies for use with Smarte Authentication as a stand-alone and in conjunction with the System. Login Management
  • Session and Security Protocols Session Security Protocols have been designed and implemented. These include a user definable time-out feature based on user inactivity, a disabling of the browser 'Back' button, and an inability of the user to have more than one session open at any one time. Also, the System uses session cookies as opposed to storage cookies. Authentication Portal
  • the present invention's Authentication Portal (Smarte Authentication) is integrated into the Smarte System and is presented as a standalone offering as well.
  • the present invention provides strong, two-factor user authentication through the use of such secure devices as CD- ROMS, ID Tokens, ID Business Cards (hard devices), and software installed on PCs, PDAs or wireless cell phones (soft devices). Entity Crossover
  • the entity structure allows a USER of the authentication system to also be a SYSTEM user.
  • Portable Digital Signatures
  • a portable repository of digital signatures Users are able to digitally sign documents from anywhere at any time by retrieving the portable repository through unique authentication.
  • FIG. 44 is an overview diagram depicting plug-in inter-system relationships that support the system.
  • End Users In order for Access to any portion of the system to be granted to an individual user, they must be recorded in the system as End Authentication Users. End Users (to whom devices have been issued) maintain no implicit direct access within the system, unless entering as an authorized user into the system via the access granted via the standard Plug-in. Therefore, no special access area exists for them. End Users are maintained at two distinct levels within the
  • the Smarte M Authentication System The first level is the "common", or system level, to which each of the End Users are assigned a unique System Identifier, that identifies the Individual, independent of membership or External Source References (including the Smarte SystemTM itself). No personal information is retained for the End User at this level.
  • the second level is at the level of External Source and External Source End User Reference (i.e.: Login Name) for the particular External Source.
  • Login Name i.e.: Login Name
  • This structure allows an individual to be identified, as well as maintain multiple devices across many different external sources where End User's login name/identifier may be different for each of the external sources. Since a Smarte Device TM is assigned to the System Level, rather than at the external source level, it allows devices to be utilized across multiple External Sources.
  • Devices Access to the system is granted to End Users via a Device.
  • Devices are initially maintained maintained by the system in an "inventory", and are grouped sequentially by “Lots”. Devices are placed into inventory via manual entry, or import of mformation from a generated import file where the devices have been serialized with a serial number string internally. These devices are issued from inventory to External Sources, for subsequent distribution to End Users.
  • the system is itself an External Source in this regard as part of the authentication requirements. This relationship is displayed in FIG. 1.
  • Access Authorizations are the "rules" defined by the external source for particular access to a single site. There are mechanisms within the system that allow for the External Source to dynamically have a single Authorization that can function across multiple access points.
  • the system is structured to allow a "parent-child” relationship, under which a single authorization can maintain a single processing set of rules, while other specific requirements can be defined under different "child” authorizations, allowing the External Source to call the "parent” authorization, while assigning the individual "children” authorizations to the specific devices as needed.
  • An example of this application would be where access is limited to specific time periods during the day based on a worker's daily shift, and there are three working shifts.
  • Functional Authorization Rules define how the Authorization functions, and directs the plug-in on the External Source Server in how to react to authorization requests. Functional rules include:
  • the Universal Password is utilized as a secondary password, which can be used as an ALTERNATE to the source's OWN maintained password.
  • End User Access Rules also apply to the realm of Product Authorization, and are maintained in the same area within the system, as for the purposes of structure, in Product Authentication, the Product Itself is considered to be the End User.
  • End User Access rules include:
  • External Sources The primary relationship between External Sources, Devices, and System Users (typically External Source employees) is as displayed in FIG 2.
  • External Source employees typically External Source employees
  • FIG. 3 The relationship between inventory and External Sources is as shown in FIG. 3.
  • the present system must itself act as an "external” entity in order to set up and maintain access rights for the Smarte System using the functions of the Smarte Authentication section. In this manner, there is only a single hardened security and access methodology employed in accessing not only the Smarte SystemTM, but External Source sites as well. This prevents having multiple "weaker” systems filled with exceptions that must be maintained within other areas of primary systems involved, such as the Smarte System TM itself.
  • Each Individual Screen within the Smarte Authentication TM system is identified by a screen "identification code", the placement is as shown in FIG. 6. If specific Screens are
  • Edit Checks are considered those validations of information that can be performed in regards to themselves, such as is the item a valid "state” or postal code; is a mandatory information entry field left blank, is an entered identification number the correct length and format, etc. These also include validations that can be performed within the same form/data table itself, such as a "date started” could not be entered after a "date ended”.
  • Guardians refer to validations that must be cross checked against multiple forms or data tables, and include protection against the entry of duplicated records, or records containing information that conflicts with other records or information limitations already in the system.
  • Spaces and Extended Characters are allowed in the Street Address Lines. for Cities, Spaces and Extended Characters are allowed.
  • the 5-digit zip code is optional, if any portion of it is entered, it must be 5-digit numeric, or made blank.
  • the 4-digit extension on a Zip Code cannot exist without the 5-digit portion being entered.
  • the four-digit zip code extension is ALWAYS optional.
  • Phone Numbers are always divided into 3 separate text fields on the screens. Where a phone # is optional, if any portion of the phone number is entered, the entire number must be entered correctly. Area Codes are always required if a phone # is entered.
  • Dates are entered and maintained in the system in DD/MM/YYYY format.
  • Device Ownership is defined as having both Complete
  • Device Ownership can be held by one and only one External Source.
  • An External Source retaining Device Ownership can grant some or all Device
  • Device Control Authority is a set of device management rights including Device
  • the External Source holding Device Ownership can grant any or all device management rights encompassed by Device Control Authority to other External
  • Menus provide the primary navigation for actions to be taken from the screens for the system users, regardless of user type.
  • System users of the system on the Server Access the system controls via the Interface.
  • Users of a Local Server version of the Authentication Server gain access into the system directly.
  • Log-In In this screen, the user enters Log-in name and password.
  • o Device Handling This screen appears, specific to the type of physical verification device that the user has been assigned. If the user has instead locked the ID to the particular machine, the alternate screen is utilized instead only if the user is downloading the "key" for the first time.
  • This screen allows a NEW user to download an encrypted algorithmic key to their individual computer on a one time basis, thereby locking their access as a member to the system to a single machine.
  • the System Screens, with relationships to each other, are displayed in FIG. 7, FIG. 8, and FIG. 9.
  • Security Officer Mode This screen requests access to Security Officer Mode, displays Officer Activity Log, etc.. Also permits a Security Officer to Return to Standard Admin User mode if in Security Officer Mode.
  • This screen is the primary screen for selecting Administrative user profiles/security settings for Add/Edit/Delete.
  • the methodology used in defining the structure of the system is one where any "thing" that either has, or could have multiple “types”, is structured so that there is a "master” table, containing information that would be common to ALL types, as well as an identifier code within this record indicating the specific "type”.
  • a "master” table containing information that would be common to ALL types, as well as an identifier code within this record indicating the specific "type”.
  • Related to this "master” data table are individual tables then that contain information specific to the individual "types”.
  • the "master” table does not have to be altered, and the addition of a specific type table is all that is then required. Based on this principle, there is no need to have to
  • Access to the system is granted to End Users via a Device.
  • Devices are initially maintained by the system in an "inventory", and are grouped sequentially by “Lots”. This relationship is displayed in FIG. 3.
  • Physical Devices are supplemental to the individual user's Standard Login and Password. Once the Login (and Password/Supplemental Information) is/are received by the Security Server, the information is then matched to the System's Database. The Type of device that the user has been issued is then retrieved by the system. Dependant upon the type of issued device, the system then requests additional information from the user, by either direct data entry or physical device insertion into the appropriate reader.
  • the information obtained is then validated via the security system, whether it can be processed internally, or passed to an outside agent, (such as the RSA ACE Server) with the Security System acting as the intermediary between the systems.
  • an outside agent such as the RSA ACE Server
  • This methodology allows the Smarte AuthenticationTM System to maintain a map between multiple systems and device types, as well as provide the future capability to allow cross platform access between participating entities.
  • the Smarte AuthenticationTM portion of the system is designed to allow virtually any device "type" to be utilized for authentication purposes.
  • the device types currently employed structured for in the system are: Smarte CDTM; Smart Card; Soft ID; and 3 r Party Tokens.
  • the Smarte CDTM is a serialized device application of a standard business card sized CD
  • Smarte CDTM is shown in FIG. 12.
  • the Smarte CDTM has the following "optional” features, of which one or both types of “serialization” must be incorporated in order for the CD itself to be a viable means of authentication of the individual user:
  • Serialized “Content” File (Style I): This file is a 220 character “intelligent” encrypted file that allows the individual CD to be tracked not only be Serial
  • Source Serialized Content File (Style II): This is simply a file that is written to the CD, based on a file list of Serial Numbers generated externally to the system. There is no encryption given for this.
  • Source Serialized Content Retention This is information retained by the system that is mapped/linked to the Serialized Label ID/Content file, based on a file list of Serial Numbers generated externally to the system.
  • volume ID label of the CD itself can be serialized, however the inherent limitation to this is the limited number of characters that can be applied to the Standard Volume Label ID. Note that while Volume ID Serialization can be done ALONE (without Serial Number Content File), without the Content file, the CD cannot be utilized with the Smarte AuthenticationTM program.
  • Standard Copy Protection Prevents most CD Burner copy software from outright duplication of the CD, however does not prevent "re-mastering" of the contents of the CD. Regardless of whether or not Serialization is included, all compliant CD's maintain a media manipulation technique in order to verify whether or not the disk is an original, or a "copy”. Details of this protection are as follows: o A single file is "corrupted" at the beginning in order to drive an I/O error from the operating system. The Defect is of sufficient size as to cause difficulties in casual copying practices, as will always generate a failure if a "pre-recording"
  • Test phase is initiated, o
  • the defect itself is specific to a standard "File", NOT a physical location on the CD Media itself.
  • the validation software looks for the file, NOT the defect, o
  • the CD's TOC is unaware of the defective area, and reports correctly the files size, etc.
  • the defect created MUST be such that the targeted area is unreadable (none or bad media format) such that it drives a system I/O error, o File Specifics
  • ⁇ Defect essentially destroys the front end of the file on the CD.
  • Smarte AuthenticationTM Original CD validation Ability to validate whether or not the CD is an original generated CD or a copy.
  • Serialized CD's can be produced from “blanks” and a single "master” content CD supplied by the end user.
  • the Smart Card is a serialized device application of a standard Smart Card in use today.
  • the Smarte IDTM Smart Card as produced by MoveMoney is about the size and shape of a standard business or credit card for each of portability. These cards initially, when issued to the External Sources, will contain NO information. Since ALL Smart Card Readers are ALSO Writers, the system has the ability to provide anti-piracy techniques through the use of "secure” Smart Cards, requiring the use of a "password” send to the card in order for the information to be read or altered. If the card can be successfully written to using the proper password, the card is likely an original and not a "forgery”. Since the system can also detect the Type of card, and the type of card requires the password, it becomes virtually immune to successful forgery.
  • Smart Card Cross Reference usability chart for External Sources to refer to as the varying Smart Cards are incorporated into the system.
  • the "type" of Smart Card itself must be maintained within the system, as programming/API calls/etc will vary from one individual card type to another.
  • the Soft ID is a program, file, or combination of these that reside on a particular machine, and allow the system to identify the individual, as being allowed to access from either a single or multiple machines.
  • these forms of identification are no as strong inherently as a physical authentication device, as they are relegated to the machine, and are as accessible for identity theft as the Soft ID is able to be copied or moved from the individual machine, or access to the individual machine is gained by an individual having the real user's password.
  • the Smarte SystemTM is stmctured/designed to allow for their usage.
  • the 3 rd Party Device type is any device, system, or combination of such that functions in a manner to physically authenticate a user's identity.
  • Devices such as RSA's SecurlD , rely not only on the device itself, but also on proprietary system's from which the validation occurs.
  • the system is designed to interact with external systems via these external system's "plug-ins" or equivalent interfaces. In this manner, a user can utilize the physical device of a third party, without having to purchase or maintain the operating system behind it, utilizing the Smarte
  • AuthenticationTM System as the portal for validation instead.
  • the Smarte AuthenticationTM System Plugin can be segregated into two basic functional classifications as User Authentication and Product (CD Based Media Distribution).
  • User Authentication is utilized as a third layer of access security to help positively identify the user, and to validate that the user is in fact, not another individual posing as that user.
  • User Authorization falls into two separate categories. This is done to highlight the varying complexities required to be maintained between the capabilities of the two systems.
  • Option I is the simple form of the usage of the system. Under this category, each user maintains only a
  • SINGLE device of a single FIXED type utilized by the external user.
  • An example of this would be a business, whereby they have chosen to utilize ONLY Smart Cards within their organization.
  • the site passes the user's login and password information to the Smarte
  • the Plug-in establishes a link to the Security server, and passes the user's password and login, the source id, and device information to the Security Server for validation. All of this information is possible in one pass, as there is only a single device type, the requirement for information device read is already known, and can therefore be requested obtained at the time of login. If Physical Device validation is required, it is also performed prior to the transmission of information. Once the Security Server receives this information, it validates against the information stored on the server within the user's profile.
  • Option II is the more complex model, and takes into account the ability of an external system to recognize multiple device types, as well as the fact that the user themselves may maintain more than one device with which to access the system.
  • the flow for Option II is as shown in FIG. 16.
  • the initial requirements and resultant action for Option II is the same as with Option I except for the additional complexity requirements.
  • the Plugin passes information between the Smarte AuthenticationTM portion of the system and the External Source Page, as well as collect information from the End User.
  • the Plug-in acts as the information "hub" of the Smarte AuthenticationTM portion of the Smarte SystemTM.
  • Information Requirements are depicted in FIG. 19.
  • SA Prime refers to the Smarte AuthenticationTM System portion of the Smarte SystemTM residing on the Server and not the Smarte AuthenticationTM Plug-in.
  • Information passed in the various segments depicted in FIG. 19 is as follows:
  • End User Login Name (or other Unique Identifier for the End User for that particular External Source
  • Personal Identifier Information #2 (Optional - Use depends on Source Activation Requirements) Existing S A System ID for User (if exists/known) Personal Information (Optional) o Name Prefix o First Name o Middle Initial o Last Name o Name Suffix o Address Line #1 o Address Line #2 o City o State o Zip Code (5) o Zip Code (4) o Voice Telephone #1 o Voice Telephone Ext (#1) o Voice Telephone #2 o Voice Telephone Ext (#2) o Email Address o SSI# Authorization Request
  • End User Login Name (or other Unique Identifier for the End User for that particular External Source that was previously passed to the SA system
  • End User Login Name (or other Unique Identifier for the End User for that particular External Source
  • End User Login Name (or other Unique Identifier for the End User for that particular External Source
  • Anti-Piracy Result Code "0" - Pirate Copy Determined; "1" Valid
  • Hash Value Authorization Request * [Note: Dynamic Strings are retained by the Plugin, but are still passed to the SA Prime for Log retention]
  • External Source SA System ID End User Login Name (or other Unique Identifier for the End User for that particular External Source that was previously passed to the SA system
  • End User Login Name (or other Unique Identifier for the End User for that particular External Source Code Block indicating type of device
  • End User Login Name (or other Unique Identifier for the End User for that particular External Source that was previously passed to the SA system
  • IP of User Within the system, there is a need for a viable, cost-effective two-factor end-user authentication solution to secure its own e-payment infrastructure platform, such as Smarte PayTM, from front-end identity assumption.
  • Available market solutions were either too cost prohibitive or too cumbersome from an implementation perspective to suit the platform's specific needs.
  • Smarte AuthenticationTM the inventors began to develop its own authentication solution, eventually known as Smarte AuthenticationTM, for integration into Smarte PayTM.
  • the success of the Smarte AuthenticationTM concept was dependent upon the development of a physical authentication device that would be suitable for mass deployments to millions of end-users.
  • the best possible device format was the CD-ROM as it offers both extreme affordability and wide-scale availability for end-user use.
  • Product Authentication is a set of tools that is provided to Software Manufacturers in order to primarily assist in combating/eliminating moderate to large scale piracy of software distributed via CD-ROM or the Internet or similar wide area network (electronic distribution).
  • Product Authentication is designed to be exclusive to MS/IBM DOS Based Microsoft Windows applications only, at this time.
  • Product Authentication is designed to allow software manufacturers the ability to prevent medium to large-scale piracy of their programs when either a
  • CD-ROM or the Internet is the distribution vehicle. Note that there are certain modifications required by the software manufacturer to make this a truly effective method of anti-piracy, however the methodology portrayed here can be only partially implemented depending on desired outcome and requirements.
  • One of the primary basic premises that the software manufacturer must make to have this methodology become effective is that they WILL have to make coding changes to the software itself at some point, in order to FORCE the user of the software to REGISTER the software, preferably, on-line via the Internet.
  • Current Anti-piracy methods completely fail, as even copy-protected CD's can be remastered/duplicated, and even the best protection can in many ways be FORGED. For example, Microsoft issues a CD "KEY" that must be entered when the software is installed.
  • Shareware typically, is a program that is designed to be freely distributed, however within the program itself, there are either certain feature limitations, or a "system fail" date/time period, which essentially allows a user to "try” the system for a specific period of time.
  • the User REGISTERS the software they are given a "registration code", of which receipt and entry of the code into the registration screen of the software UNLOCKS the software. If the Software manufacturer were to adopt a similar principle in their "standard” issued software packages, REQUIRING registration, coupled with the unique serialization of the distribution media, can virtually eliminate Piracy of the software.
  • ALL of the CD's within the individual installation "set" can be set to contain the same anti-piracy features as the initial
  • Smarte Product AuthenticationTM offers software manufacturers/publishers a flexible and cost-effective piracy management infrastructure and is ideally suited for the protection and promotion of multi-license enterprise software as well as individual consumer-licensed applications distributed on CD-ROM.
  • Smarte Product AuthenticationTM can provide the strictest possible protection to an application distributed on CD-ROM, eliminating virtually all common piracy of the product.
  • Smarte Product AuthenticationTM differentiates itself from alternative anti- piracy solutions in its flexibility of implementation. Because the infrastructure is comprised of four distinct tools that can be used in different combinations and with variable underlying strategies, the resulting piracy management can be tailored to fit company and product specific user base objectives.
  • the present invention protects software applications distributed on CD-ROM media.
  • the present invention offers software manufacturers a cost-effective anti-piracy solution that resides entirely within the CD-ROM media itself. This base level of anti-piracy technology distinguishes the contents of an original, properly licensed CD-ROM from a forgery. With this solution, software manufacturers can effectively render unusable virtually any forged application CD-ROM. Alternatively, this solution allows software manufacturers the flexibility to rigorously protect certain features and/or applications while freely allowing the re-distribution of other features and/or applications contained on the same CD-ROM.
  • the present invention alters the CD-ROM media in a way that cannot be duplicated or digitally reproduced by most CD-ROM writer hardware and software.
  • the present invention has the necessary code for integration onto the CD-ROM media whereby the originality of the CD-ROM can be efficiently validated.
  • the present invention encrypts and embeds this code during production of the product CD-ROM.
  • the application to be protected can be developed with calls to this originality validation routine.
  • the technical parameters of the routine (a DLL) are made fully available to the client's development team(s) to ensure seamless use of this tool.
  • the DLL can be called at whatever point or points a particular application needs to validate the originality of the CD-ROM.
  • the DLL When called, the DLL either confirms that the CD-ROM is a valid, original CD- ROM or determines that it is a not a valid, original CD-ROM. This key information is then passed back to the application, which would then carry out the appropriate action in line with the software manufacturer's piracy management objectives. Knowing that the media is a valid original or an illegitimate copy provides great flexibility to the manufacturer of the application to do any of the following based on that key knowledge:
  • the present invention also at the point of product replication or duplication, can uniquely encrypt and embed an identifying serial number within the content of each individual product CD-ROM.
  • the present invention has the ability to add essentially any other unique content desired by the software manufacturer (such as company specific serial numbers) to individual CD-ROMs.
  • the uniqueness that serialization provides to an individual CD-ROM makes the product a traceable identifier of the original purchaser.
  • Product serialization provides the basis by which use of an individual product (whether its an original or a duplicated copy) can be tracked and managed via the Internet.
  • the tool developed to take advantage of this capability is an Internet-based product read.
  • the serial number can be read from the CD-ROM and, therefore, tracked.
  • Foreseeable online interactions between the product user and the software manufacturer naturally involving the product CD-ROM include online registration of the product, product upgrade downloads, product patch downloads, product documentation downloads, customer service inquiries, license renewals, license upgrades, payment to render a pirated copy or feature 'legitimate', and use or unlocking of any marketing 'extras' the software manufacturer may choose to include with the product.
  • serialized CD-ROMs serve to protect the online identity of the purchaser as well as provide the software manufacturer with strong transactional non-repudiation (protection against Internet-based identity fraud).
  • the full product purchased by the customer could contain several applications in addition to the intended purchase. Even though burned as full products onto the CD-ROM, these additional applications could be presented to the customer in limited formats such as demo packs or trial versions.
  • the present invention can provide the necessary infrastructure (an enhanced Dynamic Link Library) to generate a unique authorization code (an encrypted number) based on elements taken from each of the following: the unique serial number contained in any serialized CD-ROM possessed by the customer, a time factor, and a factor unique to the software manufacturer.
  • the validity of this generated authorization code can be time-limited (by date, for instance) to prevent its unauthorized sharing with respect to the application it serves to unlock.
  • the customer would then use this authorization code (within the specified time limit) in conjunction with the serialized CD-ROM to enable an install of the application.
  • the software manufacturer could further support the integrity of the application with other piracy management tools such as Internet-based installation tracking and/or additional CD-ROM originality validation checks during use of the product. Because Smarte Product AuthenticationTM strongly supports the protection of electronically distributed software, use of the CD-ROM as a primary source of product distribution can be eliminated.
  • CD-ROM serialization and protection methodologies enable the software manufacturer to be as creative as possible when distributing or marketing software products.
  • Some marketing applications enabled by Smarte Product AuthenticationTM are outlined in the following:
  • the software manufacturer can bundle any combination of full products, limited-use versions, trial versions, demo versions, and license packs on the same CD-ROM (capacity- limited) or set of CD-ROMs. These product types can be distributed in conjunction with purchased applications or simply as enticements to purchase. Customers or potential customers can easily and efficiently purchase and register the product online through the software manufacturer (or its designated agent) as well as receive the means necessary to gain access to the purchased application.
  • the software manufacturer can develop and distribute product bundles based on regional demographics and competitive landscapes.
  • piracy management tools enables the rental of applications and application licenses both through electronic distribution and through traditional brick-and-mortar outlets.
  • software rental marketing schemes become viable, protectable options for the industry.
  • piracy management can be used to eliminate the need for enterprise software manufacturers to use floppy diskettes as the (unprotected) medium for distributing license related serial numbers and encryption keys.
  • the CD-ROM containing the enterprise application can be burned with the necessary enterprise license related serial number and unique encryption key in addition to the present invention's unique serialization of the CD-ROM. In this manner, the CD-ROM would become the only media the enterprise customer would need to maintain as it contains both the application and the necessary license information.
  • the unique license information can be burned on a serialized CD-ROM separately from the application. This would, in effect, replace the enterprise software manufacturer's current use of the floppy with a protected CD-ROM. The enterprise customer would still maintain an application CD-ROM along with another CD-ROM containing the license information for that application. This scenario would enable the application CD-ROM to still be burned without media manipulation and, thus, allow it to be archived by the customer.
  • the present invention's piracy management technology can be used to track the number of installations by unique product serial numbers. This would require an online interaction (perhaps during product registration) between the application manufacturer and the legitimate purchaser of the product in order to record the application's legitimate installation. With this knowledge, the manufacturer can choose to deny further installations of the same original product beyond legitimate customer service related issues.
  • the software manufacturer could choose to require a simple media originality check to be performed by the enterprise application to ensure the user owns a valid, original license and/or application. These checks could be required periodically (weekly or monthly, for instance) and/or the software manufacturer could choose to require the original CD-ROM to present during general or particular use of the enterprise application. Failure of these checks could be programmed to result in time-delayed termination- of-use of the enterprise application.
  • serialized product CD-ROMs can be conducted by the production house(s) of the software manufacturer's choice.
  • the present invention does have the capacity to act as a serialized product CD-ROM production house.
  • the software manufacturer would supply an import file to the production house containing all unique licensing infoimation (and/or other unique information such as the software manufacturer's product specific serial numbers) that can then be directly read into replication management software along with any common content (the application files, for instance) to be burned onto all CD-ROMs in a particular batch. All content common to a set of product CD-ROMs is replicated (stamped) from a glass master. A small portion of the CD-ROM media is left open (available for a single post-stamping write to the CD-ROM) for all individualized content.
  • the CD-ROMs containing the common content are then sequentially written to with the necessary unique content supplied by the software manufacturer (from the import file), the copy protection mechanism, and a supplied serial number (enciypted).
  • FIG. 42 The functioning of developed replication/duplication management software is depicted in FIG. 42 for single set serialized CD-ROMs and in FIG. 43 for sets of serialized CD-ROMs.
  • FIG. 41 For non-serialized CD-ROMs containing only the media-based copy protection, the functioning of developed replication/duplication software is depicted in FIG. 41.
  • the software manufacturer would determine how to use piracy management tools within its products/licensing structures to best support its anti-piracy and marketing objectives.
  • calls to the piracy management tools would be embedded within the product code along with the necessary logic to instruct the application to act accordingly, based on the infoimation the piracy tool(s) pass back.
  • the software manufacturer would determine where and how frequently the use of the piracy management tools occurred within a given application, to best support piracy management objectives.
  • Enterprise Software AuthenticationTM is a tool that enables enterprise software developers to effectively and efficiently create, as a value-add feature, a sound device-based user authentication infrastructure within access sensitive enterprise products.
  • the end result of the methodology gives the enterprise customer the ability to secure access to its software application with strong two-factor user authentication, combining 'something the user knows' with 'something the user physically has' - all without the need for drivers or additional support software.
  • the devices, which provide the definitive layer of user authentication, are uniquely serialized mini-CD-ROMs, Smarte CDTMs.
  • the CD-ROM format delivers affordability, convenient portability, security against forgery, branding opportunities, and complete end-user privacy (no personal information is required).
  • Enterprise User Authentication is a strong value-add feature in software application environments where strict access control to the application itself and/or data generated through the application is of prime importance to the business or organization using the application.
  • the present invention provides the manufacturer of the software with the necessary tool around which a strong user authentication infrastructure can be built within an application.
  • This tool is essentially an 'Extended DLL Plug-in', which serves to create and manage data files governing the user and associated authentication device information.
  • FIG. 26 depicts a diagram displaying the Extended DLL data file structure.
  • FIG. 27 is a flow chart depicting the basic functional flow of the "simple" DLL (media validation function only), while FIG. 28 is a flow chart depicting the basic functional flow of the Extended DLL.
  • An application developed with the Enterprise Software Authentication tool can be delivered with a software-based switch that allows the enterprise customer the option to use or not to use the Enterprise Software Authentication feature.
  • the CD-ROM user authentication credentials can be delivered at the point of sale of the application or at any later date when the enterprise customer chooses to use the feature.
  • the DLL Plug-in in the context determined by the application developer, provides the means necessary to effectively manage the application's authorized enterprise user base.
  • the software developer can shape the use of the DLL Plug-in to fit the exact user base access management needs of the enterprise product.
  • KillExistingUser Private Declare Function KillExistingUser Lib "c: ⁇ windows ⁇ system ⁇ SmarteAuth.dU” _ (ByVal DataFile As String, ByVal Pwd As Stiing, ByVal Userld As Stiing) As Stiing dim Result
  • HINSTANCE hDLL // Handle to DLL
  • AssignDeviceQ typedef char* (CALLBACK* LPFN)(char*,char *,char *,char *,char *,char *,char *,char *,char *,char *,char *,char *,char *,char *,char *,char *,char *,char *,char *,char *,char
  • IDDeviceQ typedef char* (CALLBACK* LPFN)(char*,char *,char *,char *,char *,char *,char *,char *,char *,char *,char *,char *,char *,char *,char *,char *,char *,char *,char *,char
  • the Smarte CDTM may have any or all of the validation and serialization methodologies applicable, depending on the CD usage. For example, for User Access Authentication, ALL of the methodologies may be employed, however, for Product Validation, only some of these methodologies may be chosen to be used by the supplier of the software.
  • the validation process for the Smarte CDTM is displayed in FIG. 21.
  • Smart Card Like the Smarte CDTM, there is a specific validation flow for the Smart Card, as shown in FIG 22. Unlike the Smarte CDTM, however, the Smart Card is used solely for User Authentication, and therefore the validation process and methodology for the Smart Card is fixed.
  • FIG. 23 The specific validation flow for Third Party Devices is as shown in FIG. 23.
  • it is the Smarte AuthenticationTM portion of the Smarte SystemTM that interacts with the external authentication server or software.
  • this validation flow is displayed.
  • the external authentication mechanism is displayed as a separate physical server, however it could easily just as well be a program running in the background on servers. This flow is valid regardless of physical proximity or location to the servers, the requirement only being a clear and secure communications channel to exchange information.
  • FIG. 25 uses the RSATM ACETM Server as an example, to display a "typical" set-up, include recommended "hardware" involved.
  • FIG. 24 The basic flow for the Authentication Process is represented in FIG. 24.
  • the system receives purchased devices/device media, and adds to inventory as required dependant upon the type of device. Depending on the device type, one of the following will apply as applicable:
  • the system Generates Serialized CD's From Inventory
  • the system Generates Serialized Smart Cards from Inventory
  • the system may include 3 rd party devices as required
  • the system issues the devices to the External Authentication Sources for Distribution to End Users and/or Internal Use.
  • the present invention utilizing the Authentication Issue Screens issues the devices to the applicable Extemal Source either by Lot, Device Serial Number Range, or SINGLE device. This results in "ownership" transfer to the applicable External Source.
  • the External Source retains ownership even after assigning a device to an End User, as it is the External Source who retains control over the device and the options for that device. As the Device Ownership is conferred, so to is Complete Device Control Authority for each of the devices Issued.
  • the External Source receives the devices from the present invention. It is up to the External Source how it wants to physically distribute devices to its end users - through mail, in person, or by 3 rd Party, for instance.
  • the External Source will Attach Access Authorizations to each device. This can be done individually or in a "bulk” group (many selected Authorization Masters against many individual devices) as needed.
  • the External Source "Activates" the particular device manually in system, entering any applicable back-up information as required based on the activation.
  • Another mechanism for activation of a device that can occur is where the End User "Remotely" activates the device, based on additional information sent to them, personal information previously known to the External Source, or a combination of this. In this case, the End User performs this activation of the device via entry into a "special" area of the Smarte SystemTM.
  • the basic flow requirements for this are as follows:
  • End User "Activates" Device Automatically o End User receives and physically has the device in their possession. o End User is provided a URL to go to for automatic device activation.
  • End User goes to the URL provided [EUAS01, EUAS02] and is prompted for device specific information (serial number printed on the device).
  • End User receives and physically has the device in their possession.
  • 3 rd Party User retrieves the device number (printed on the device) from the
  • THEN 3 r Party User retrieves the personal identifier information from the End User.
  • 3 rd Party User enters the personal identifier information.
  • the device is activated.
  • o 3 rd Party User is given confirmation that the device is activated.
  • o 3 r Party User notifies the End User that the device is activated.
  • Device can also be activated at the same time as Assignment by the system. This is used primarily where direct physical contact and physical identification of the End User occurs.
  • Device Ownership can be transferced either in groups by Lot or Serial Number Range.
  • External Source User chooses the method by which Device Ownership is to be transferred.
  • the device(s) to be transferred are selected (by Lot or Serial
  • the system prompts the External Source User for the External Source ID to which Device Ownership is to be transferred.
  • the system checks that the External Source from which Device Ownership is to be transferred does, indeed, hold Device Ownership for the selected device(s).
  • the system For any breaks in the master series (breaks defined as Device Ownership not held by the External Source), the system generates new Lot designations for unbroken sub-series existing within the master series. The system then Transfers Device Ownership to the new
  • Granting of any Device Control Authority can only occur from the holder of Device Ownership to another External Source, i.e. the External Source receiving the Grant of Device Control Authority cannot further delegate that authority to another External Source.
  • the External Source holding Device Ownership can, however, Grant the same type of Device Control Authority to multiple Extemal Sources.
  • the system To Grant Device Control Authority, the system must know the Devices for which Control Authority is being Granted (by Lot or System Serial Number), the ID of the External Source to which the Device Control Authority is being Granted, the ID of the holder of Device Ownership, and the specific types of Device Control Authority being Granted. The system should check that the External Source that is granting the Control Authority is, indeed, the holder of Device Ownership for the selected devices. To Grant, the system must extend those chosen management rights for the selected devices to the designated External Source.
  • Plug-in acts simply as portal for information to pass. All validations of acceptance/rejection performed on the Security Server.
  • Login is routed via Smarte AuthenticationTM Plug-in.
  • Plug-in acts simply as portal for information to pass. All validations of acceptance/rejection performed on the present invention's Security Server.
  • Via Plugin Smarte SystemTM Login.
  • Login is routed via Smarte AuthenticationTM Plugin OR Plugin "simulated" code as part of Smarte SystemTM itself.
  • Plug-in acts simply as portal for information to pass. All validations of acceptance/rejection performed on the present invention's Security Server.
  • the Co ⁇ orate Security Policy is a high-level document that states senior management's directives for the co ⁇ oration's overall security.
  • Digital certificates and Tokens are used for user authentication.
  • Digital certificates and secret key encryption are used for process authentication.
  • Authentication, authorization, access control framework products provides more security than basic operating system capabilities.
  • Security policies ensures that the system defines overall security responsibilities and defines consistent guidelines for performing security-relevant functions. Encryption provides both data confidentiality and data integrity. The system will not be able to control the Seller's web site that the Smarte VIITM platform will be installed in. Thus, some of the components operate in a "hostile" environment. The system applies least privilege concepts to restrict the capabilities of these components, as well as limit the sensitive information these components can access. The co ⁇ orate security policy covers these areas: Issue statement: The policy's goal, the definition of the issue. The primary goals are to maintain high integrity, to prevent fraud and to prevent unauthorized disclosure.
  • Position statement Management's decision on how the issue is approached. Applicability: Where, when, how, to whom, and to what the policy applies. Applicability specifies the facilities, hardware, software, information, and personnel that the policy covers. Roles and responsibilities: The management and technical roles to implement the policy and to insure the policy's continuity. This also outlines the organizational responsibility for operational security and defines employee accountability. Compliance: The policy's definition of how violations are handled and disciplinary actions, such as penalties. Monitoring responsibilities are covered in the responsibilities statement.
  • the system supplements the overall co ⁇ orate policy with detailed operational policies. These provide specific security rales for particular systems, such as the rules and practices that regulate how a system manages, protects, and distributes sensitive information. Examples of operational policies include policies for physical security, platform hardening, disaster recovery, and Internet usage.
  • Session ID's are kept long, e.g. 30 characters or more; be random and not repeat over time; not contain any user infoimation, but are tied server-side to a specific user ID; expire within a reasonable time period (e.g., minutes, not days); and be sent over a secure path.
  • the system tracks the user's IP address to avoid IP hopping (changing the session IP address during a session), a probable indicator of session hijacking.
  • the same User ID will not have multiple sessions at any given point of time.
  • Temporary files are avoided, and are automatically deleted as they can provide sensitive information to others if file system permissions peimit access or if the system is hacked. Moreover temporary files occupy disk space and hence are automatically deleted from the system. Writing of temporary files to publicly accessible directories, such as /tmp are avoided.
  • Session data are not cached on the user's system.
  • Log out pages are not cached to prevent another user to use the browser back key to view session data.
  • Session timeouts are auto programmed. Users are instructed to close their browser if cookies or other session information may persist. This is done by "in your face" mechanism such as a browser pop up.
  • Strong ciphers are used to protect information. Web servers are set to require specific ciphers, not negotiate a common cipher set. Otherwise, user could set their browser use no ciphers or message authentication codes, leaving the connection vulnerable to eavesdropping. Key length may have an impact on application performance. Applications are tested with different key lengths to understand the application impact.
  • Session resources are not allocated until after the user has successfully authenticated. Otherwise, partial authentication attempts floods could exhaust server resources. Explicit session connection timeouts are set.
  • Sensitive information such as, User Ids and passwords, Encryption Keys, Transaction Data, Credit card numbers, Account numbers, Internal system names and IP addresses and internal user account ID's are especially avoided to be left in clear-text.
  • Browser-side checks are not reliable. JavaScript, VB Script, or other scripting checks done in the user browser can be easily circumvented. These checks are considered a convenience to the user. All checks are duplicated on the server.
  • Hardened Server Platform All unnecessary services from the operating system are removed. Extraneous services that may be packaged with the web service (e.g., FTP, file upload, Gopher) are disabled. All unused user ID's are removed. Password rales, especially for administrator accounts are enforced. Strong authentication for administrator accounts, especially for externally accessible systems are applied. Contents in the web server's environment are made known and PATH settings are kept as minimal as possible and absolute paths are maintained. Security patches are kept up to date; system settings are rechecked after patching. Web server admin function are shut down when not in use. Admin functions that are HTML- based, are not externally accessible.
  • the supporting services that underlie application services are also hardened, and therefore operate securely as otherwise they could be used to provide infoimation for attacks, or as attack launching points. These services are also hardened against Internet intruders.
  • the service provider maintains awareness of current Internet attacks and provides basic services such as IP address spoofing filtering and attack monitoring. (IP address spoofing is where a hacker discovers an IP address assigned to an internal host and uses it in traffic that they send from the Internet.)
  • IP address spoofing is where a hacker discovers an IP address assigned to an internal host and uses it in traffic that they send from the Internet.
  • the service provider service contract defines their responsibilities for alerting the system if the provider detects an abnormally large amount of traffic going to the system site.
  • the system will review its service agreement to ensure that it contains provisions for basic security services.
  • the agreement will clearly state the service provider's responsibility and time windows for notifying the system of suspicious Internet activity.
  • IP-based access restrictions IP address restrictions is used in conjunction with a DNS reverse lookup. This check verifies that the IP address is registered in a valid DNS map, and that the DNS map has matching entries for IP-hostname and hostname-IP. This helps prevent IP spoofing attacks.
  • Directly accessible content on all systems involved in the application especially externally accessible systems are outlined.
  • Directly accessible ports on every system are outlined.
  • Directories indexed for search are outlined.
  • Directories containing restricted files or sensitive information are not indexed.
  • Directories are not browsable, especially directories containing sensitive information, configuration files, or application executables.
  • Security configuration recommendations for customers to warn them about potential risks are developed. The following are a part of the system: User browser option settings, such as disabling caching encrypted pages to disk; file system permissions settings for unmasks and application file system permissions; platform hardening; required Service account privileges; and environment settings needed for the application.
  • the present invention's production systems is tightly controlled, both for security and stability via a Secure Administration.
  • the system administers its production systems itself.
  • Secure administration approach includes: Monitoring: Event notices transmitted over un-secure media can be viewed, altered, or lost.
  • Event notices can potentially give outsiders information on the type and configuration of the internal system components.
  • Remote administration is done with extreme care and limited to only a small specific group of individual user computers, as otherwise it can introduce security holes by transmitting privileged user authentication infoimation over a network where it may be monitored and recorded.
  • privileged commands may also be transmitted in the clear, where they can be recorded and replayed. Administrators have not left any backdoors in remote systems to facilitate remote access.
  • Security criteria is included in the administration tool selection criteria.
  • Features that strengthen the tool's security include support for strong authentication and replay attack prevention features.
  • Security principles define the fundamental security concepts for the system.
  • the system has these principles:
  • Resource privileges to subjects are the ability to create, modify, and delete resource instances, and to read and write resource attribute values.
  • the financial institution user can view and change the buyer's account information, or can delete the account.
  • Subjects can authorize other subjects to have access to the subject's resources.
  • the financial institution can grant a buyer the ability to create specific new information within their (the buyer's) account, such as address book entries, and to modify other data, such as the default shipping method.
  • the financial institution retains the right to view any of the buyer's data, such as for customer service.
  • Subjects can create subordinate subjects.
  • Example - buyers may create sub-buyers who may access the buyer's account.
  • Subjects can control the authorizations of their subordinate subjects.
  • Example - a buyer may authorize a sub-buyer to only be able to view transaction histories. The sub-buyer cannot create new transactions.
  • the main Application Security Components for the distributed applications are as follows:
  • Authentication component assure a subject's identity, that is, the subject is in fact who it claims to be.
  • Authorization and access control component assign privileges to subjects and control subjects' access to resources based on those privileges.
  • Accountability component uniquely traces a subject's actions to it.
  • Data integrity component assures data is not altered without authorization.
  • Confidentiality component assures data is not disclosed without authorization.
  • the system requires subjects to pass Authentication at system entry points, i.e., the external service perimeters and internal system boundaries. At each point, the system requires one-way or mutual authentication.
  • External entry points are accessible from the Internet. The entry points are:
  • Web server End users authenticate before they will be allowed to manage their profile via the web application.
  • Payment server o Buyers are authenticated before they will be allowed to access their account for payment. This authentication is passed through the seller's web application to the payment server via the Smarte VIITM platform. o Seller systems authenticate to the payment system before they can submit transactions. Internal service points will be accessible to internal systems and users. The entry points are:
  • Admin server Administrators are authenticated before they are allowed access to administrative applications.
  • Application server Depending on the security of the internal LAN, direct access to the application server requires authentication.
  • the remote access server acts as a gateway between a remote location and the systems at the service provider facility so that employees can administer the operational systems.
  • the remote access device may be a separate device, may be integrated with the service provider firewall, or may not be used if the communications link is a private leased line.
  • Database server The database server requires authentication to access the database.
  • the system uses two main categories of authentication: User (human) authentication and
  • Process authentication for inter-process interactions User authentication prompts the user to enter authentication information. With process authentication, the process invokes the authentication mechanism automatically. Since the SmarteTM suite of offerings deals with payment and financial institution accounts, the system uses very strong authentication mechanisms. Most credit card services do not use strong authentication, so this provides the system increased security over most credit card services.
  • Challenge/response The system produces an unpredictable challenge that varies with time. The subject generates a response, using secret information known only to that subject. The system adopts the challenge/response based on digital signatures and public key certificates.
  • the subject is given some data that it must digitally sign to prove its identity.
  • the recipient of the signed challenge verify the signature with the subject's public key.
  • Digital signatures are based on RSA algorithms, the most prevalent in the industry today.
  • the subject being authenticated has public key/private key pair and public key certificate. For others to accept the subject's public key certificate as genuine, the certificate is issued by a trusted third-party.
  • the subject's private key is protected, as it constitutes the actual proof of the subject's identity.
  • Secure Sockets Layer (SSL) uses this form of challenge/response authentication.
  • Smart cards or Custom CDs are used to store the private key and certificate. The card or CD can perform the cryptographic functions so that the private key is never exposed.
  • Smart cards require the subject to have a smart card reader and Custom CDs require the subject to have a CD ROM drive.
  • Key pairs can be generated by browsers and stored in the browser's key database, but this renders them susceptible to theft. Key pairs for special use uses RSA's
  • Token A token is something that a subject possesses that they present as part of their authentication.
  • the system will use RSA SecurlD for the Token authentication. This is a physical or software device that displays a time-varying multi-digit number (the number changes once a minute). To authenticate, the subject must present their user ID, the current number, plus the PIN they get assigned when they signup.
  • Another important facet of an authentication component in the system is how failed authentication is handled.
  • the failure handling will not reveal any additional infoimation about the subject or why the authentication failed (e.g., an error message will state "authentication failed” not "invalid password” or "invalid user ID”). Limiting the number of authentication retries prevents guessing attacks.
  • Repeated login failures generates a security event to detect systematic attacks. The system logs these events. The system also supports sending notices to the owner of the account experiencing the failed logins.
  • Authentication state tracking is an important part of session management for web applications. The web application distinguishes each authentication phase so that subjects cannot bypass authentication.
  • Authorization consists of granting one or more privileges to a subject.
  • Authorization mechanisms assigns privileges at different granularities. For financial systems, granular privilege assignments are required. Since financial account data is highly sensitive, the system assigns permissions for viewing, modifying, and deleting to specific resources.
  • the authorization system supports the ability for subjects to allocate some or all of their privileges to other subjects, but constrains the allocation so that subjects cannot give away privileges they do not have.
  • the creating subject assigns privileges to the new subject so that the new subject can access its profile and its funds.
  • a user can explicitly grant privileges to a sub-user.
  • delegation In delegation, a subject authorizes another subject to act on its behalf, with some or all the original subject's privileges. For example, a process will assume a user's identity and perform actions on the user's behalf.
  • the authorization database and authorization assignment functions will be secure or subjects will be able to adjust authorization assignments themselves.
  • Access Control mechanisms enforce the permissions a subject must have to access resources.
  • Access control can be controlled with widely differing granularity, ranging from no access controls to controls on individual resources within applications, such as fields within database records.
  • the system requires access controls with the ability to support a wide range of granularity, in particular, it enforces that subject's have the required permissions before granting access to sensitive resources. Access controls thus applies to all subject types, human and machine.
  • the system employs the following access controls:
  • Intrinsic permission enforcement controls that are built into the operating system.
  • the operating system enforces owner/group/public permissions for read/write/execute.
  • Policy objects An object-oriented approach to access control, where a policy object defines the attributes needed to access a resource. Subjects are assigned privilege attributes; the policy object maps authorization privileges to access rights.
  • Container-based A container provides an execution environment for entities that reside within in it. Part of this environment is access control based on the container's security policy.
  • Access control lists A permission list associated with a resource that defines the privileges a subject must possess in order to gain access to the resource and the type of access the subject is permitted.
  • Rules define a set of characteristics or conditions that must be met before access is granted.
  • Capability-based A capability identifies an object and a set of access rights to that object. Any subject that holds the capability can use it to perform the operations permitted by those rights. Capability-based security is efficient because no special checks are needed to verify that a subject has a particular permission; the possession of the capability signifies that permission has been rightfully obtained. Internal access points occur whenever a subject or process accesses a resource. Access controls are applied whenever a subject requests access to a resource. Caching permissions can improve performance, as can dynamically adjusting the function set made available to a subject so that the subject only "sees" permitted functions. For example, a user's GUI is dynamically constructed so that the user only sees the menu items they are authorized for, reducing the access control checking needed in the GUI. Web applications need to pay particular concern to access controls, since some users will attempt to subvert access controls wherever possible. Issues that are considered include:
  • Menu bypass If users can gam information on how menu items are invoked, they may try to bypass the menu system and invoke functions directly.
  • the menu system does provide information on how internal functions are accessed. Direct invocations of web resources.
  • Java servlets can be accessed by directly connecting to their URL. Unless the servlet first applies access controls, this may enable a subject to invoke the servlet' s functions without authorization. Implementing access controls in all servlets is highly redundant. Therefore a central servlet dispatcher that performs the access check, then dispatches the correct servlet for the function is implemented for efficiency. Inte ⁇ rocess communications.
  • Session information is sent to the user's browser in three main ways: o A cookie. This is stored in the browser-specific cookie store. Since the cookie is in a file, the user must find the cookie file to view the cookie. In addition, the cookie itself is a session value, so no hard file is stored, making it more difficult to capture. In addition, the web application expects that users might tamper with cookies. Integrity checks are applied to help detect tampering, o A hidden field. This information is encoded in HTML tags within the form itself. The user can view the session ID by viewing the page source, o URL encoding. The session ID is appended to the URL in a particular format. The session ID is visible at all times.
  • Accountability mechanisms ensure that a subject's actions can be uniquely traced to it. Two accountability mechanisms are applied to the architecture: audit logging and non- repudiation.
  • Audit logs record a permanent trace of a subject's actions.
  • An audit policy defines the security relevant events that are recorded, for example log on, log off, failed authentication, and other events that affect system configurations or sensitive user application data. The policy also defines what actions to take when audit logs reach their maximum size.
  • All audit log records are sent to a central audit facility.
  • the audit event notices adhere to a standard format.
  • An event notification protocol transmits the event notice from the emitter to the central collection system.
  • RSA Security Keon Event Logging Server's advanced PKI products and Emails route event-logging information to a centralized Event Logging Server (ELS) against which reports may be run.
  • ELS Event Logging Server
  • Monitoring products filter log records for patterns of events that indicate potential security incidents. Some products automatically generate alerts to administrators. Administrators can thus receive one meaningful notice as opposed to many low level events.
  • Secondary event notices are generated as a result of an event or a combination of events. For example, the system logs failed authentication attempts, but also forwards an event notice to the account holder and to administrators in the case of repeat authentication failures.
  • the audit records are archived for a period long enough to support potential investigations. In addition, the records are protected against change in case a dispute or security incident needs to be investigated. Periodic audit reports are generated as a useful management tool since
  • Non-repudiation mechanisms provide proof that a subject participated in an action.
  • the exact nature of the proof required vary according to the laws in the jurisdiction. Proofs that may be required include proof that the sender intended to perform the action (e.g., buy something), proof that the transaction actually came from the sender, proof that the transaction has not been altered since the sender initiated it, proof that the communication between the two parties occurred, and proof that the transaction record has not been altered.
  • Non-repudiation is a complex subject, since the legal requirements for evidence are not the same in all jurisdictions. In the United States, non-repudiation is tied to digital signature legislation. Cmrently, the States are enacting their own legislation, as is the Federal government. The situation overseas is about the same.
  • Time-stamps The application applies a timestamp when the signature is applied. Without this, the application cannot check that the certificate was valid at the time the action took place. The timestamp is "secure", i.e., unforgeable. Secure audit trails. Records of the non-repudiation action is stored so that they cannot be changed after the action has occurred. Digital signatures are a primary means of obtaining non-repudiation. Multiple digital signatures may be needed to achieve non-repudiation sufficient for a legal contest. Non-repudiation can occur at multiple levels in the application:
  • the endpoints in the communication session such as an SSL session, exchange a secured data structure, such as a digital signature, that authenticates them. This validates that a session between the sender and receiver took place.
  • ORBs include a secured data stracture, such as a digital signature, that validates the service's authenticity. Interactions are securely time-stamped and logged. This validates that an interaction took place.
  • the tiansaction is accompanied with a secured data structure, such as a digital signature, that validates its authenticity; the transaction is time-stamped and logged. This validates that a transaction took place.
  • a secured data structure such as a digital signature
  • the end-user's intent to take the action is recorded, the application actions are uniquely and irrefutably traced to the user by the user digitally signing the transaction data, and the action is securely time-stamped and securely logged. This validates that the user's intent to engage in the action and that the action took place.
  • Data Integrity mechanisms ensure that data has not been altered or destroyed by unauthorized subjects.
  • Data integrity mechanisms are usually based on hash functions that use a one-way immutable function to produce a unique value from the variable length input data.
  • Simple checksums produce a hash using low-overhead algorithms. Encrypted checksums are simple checksums that have been encrypted using a secret key. An encrypted checksum is harder to alter than a simple checksum.
  • the SSL protocol uses an encrypted checksum called a message authentication code (MAC) to detect changes to data while in transit. Digital signatures combine a hash function and asymmetric encryption to construct a secure encrypted hash of a specific set of data. Data integrity mechanisms apply primarily to data. Data integrity are applied to the sensitive user information, including user and transaction data stored in the database.
  • Encrypted checksums are simple checksums that have been encrypted using a secret key. An encrypted checksum is harder to alter than a simple checksum. A special case of an encrypted checksum is a message authentication code (MAC). Encrypted checksums are encrypted with RSA asymmetric encryption. Encrypted checksums are typically applied to data where change detection is important. Common uses are audit records of financial transactions where they transaction may later be disputed.
  • MACs are one-way hashes produced using secret key encryption. MACs are primarily used in communications sessions to verify the data's origin and that the data exchanged was not altered en route.
  • SSL The SSL session's master secret is hashed into a sequence of secure bytes. Part of the secure bytes are used for a MAC secret. The MAC secret is hashed with the message data, then hashed again with the results of the first operation. The output of the MAC operation is encrypted according to the negotiated session cipher specification.
  • Digital signatures combine a digest function and asymmetric encryption to construct a secure digital signature of a specific set of data.
  • a digital signature is a digest computed over a specific set of data using a message digest algorithm.
  • the computed digest is then encrypted with a private key.
  • the signature is verified by re-computing the digest with the same algorithm over the same data set.
  • the signature is decrypted with associated public key, and the decrypted digest value is compared with the original digest. If the values match, the signature verifies; otherwise verification fails.
  • Key distribution Delivering keys to subjects are done electronically through participating Financial Institutions or Exchanges.
  • Keys are changed periodically. Updating a key reduces the risk of the key's exposure over time. Key update involves not only key distribution for the new key, but keeping track of when keys are due to expire.
  • Key revocation If a key is exposed, it will be invalidated so that it can no longer be used. This can be as simple as refusing to accept the key, if the key is only used in pair-wise connections. Asymmetric keys would be reissued through the certificate authority. The certificate authority will revoke the public key certificate and include the certificate in the certificate revocation lists that it issues.
  • Encryption keys will be stored in a secure backup facility. If the keys are lost, the backup copy of the key can be used to replace the lost key. Confidentiality mechanisms ensure that information is not disclosed to unauthorized subjects. Confidentiality mechanisms are usually based on encryption, where symmetric key algorithms, asymmetric key algorithms, or both, may be used. As with the data integrity service, the confidentiality services also primarily apply to data. Data confidentiality applies to data in transit and data in storage. The main categories of data integrity mechanisms are as follows:
  • Symmetric key encryption All parties authorized for the data will have an access to the decryption key. Symmetric key encryption are applied for pair-wise confidentiality, e.g., only the data owner and the system are authorized for the data. If more subjects are authorized, then group encryption keys are needed. Public key encryption: For confidentiality, the asymmetric keys are used in the opposite fashion from a digital signature - the subject's public key encrypts the data, then only the holder of the matching private key can decrypt the data. This provides strong individual privacy protection since only the private key holder can access the data.
  • Proprietary Encryption In addition to the standard, additional encryption routines may be utilized for data that is not of a "critical" nature, but should still be afforded some measure of protection.
  • the SSL protocol encrypts data in transit between the user browser and the External Source's web server with symmetric key encryption.
  • the system minimizes any sensitive information sent to or stored in their components on the seller's web server.
  • Web server to application server or database, payment server to application server or database The web server and payment server is externally accessible, the application server and database are internal systems. The system works with its service provider to ensure that data passing from externally exposed systems to internal systems is not be externally visible.
  • the application server resides in the internal environment. Sensitive information that the application server places in persistent storage or cache are protected.
  • Database storage Sensitive information that are stored for a long time are protected against exposure. This reduces the chance that an employee can inadvertently or deliberately access the information. It also makes an intruder's ability to access infoimation harder.
  • ODFI This will be a private interface.
  • the ODFI has its own interface guidelines; and the system has ensured that their information's security is protected.
  • the privacy service's use of encryption addresses the issues of Key Management and
  • Failures may or may not be caused by security problems; however, if they are not handled within specific time periods, the effect can be the same as a successful denial of service attack.
  • the system inco ⁇ orates the following:
  • Integrated system and application monitoring includes the DMZ systems and supporting services.
  • the strategy addresses how outages are detected and to whom they are reported.
  • Disaster recovery planning covers procedures for a wide ranges of potential outages, from simple system failures to more catastrophic, widespread failures.
  • the system has recovery plans for its applications so that recovery responsibilities are clear and can be tested consistently.
  • Internet attack recovery is a special case that will be addressed in the disaster recovery plans.
  • the recovery assigns responsibilities to the service providers and to the system.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Multimedia (AREA)
  • Technology Law (AREA)
  • Storage Device Security (AREA)
  • Signal Processing For Digital Recording And Reproducing (AREA)

Abstract

L'invention concerne un système sous forme de logiciel offrant des solutions nouvelles et uniques au besoin de sécuriser des environnements numériques. Cette invention met en oeuvre des formes innovatrices et nouvelles d'authentification d'utilisateur à facteurs multiples et de gestion d'identités numériques, permettant d'obtenir des niveaux de sécurité sans correspondance dans l'industrie. En outre, ce système offre des procédés nouveaux et uniques de gestion de piratage logiciel, notamment la protection de copies à base de support CD, la validation de support CD à distance, la sérialisation de produits intégrée, la protection de logiciel distribué électroniquement, et le suivi à distance de l'installation de produit.
PCT/US2002/032292 2001-10-16 2002-10-15 Authentification d'utilisateur/produit et systeme de gestion de piratage WO2003040869A2 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU2002347849A AU2002347849A1 (en) 2001-10-16 2002-10-15 User/product authentication and piracy management system

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US98125101A 2001-10-16 2001-10-16
US09/981,251 2001-10-16

Publications (2)

Publication Number Publication Date
WO2003040869A2 true WO2003040869A2 (fr) 2003-05-15
WO2003040869A3 WO2003040869A3 (fr) 2004-03-04

Family

ID=25528236

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2002/032292 WO2003040869A2 (fr) 2001-10-16 2002-10-15 Authentification d'utilisateur/produit et systeme de gestion de piratage

Country Status (2)

Country Link
AU (1) AU2002347849A1 (fr)
WO (1) WO2003040869A2 (fr)

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2006090392A2 (fr) 2005-02-24 2006-08-31 Rsa Security Inc. Systeme et procede de detection de chevaux de troie procedant a la mystification de dns et de lutte contre ces derniers
WO2007027153A1 (fr) * 2005-09-01 2007-03-08 Encentuate Pte Ltd Systeme d'authentification portable et de commande d'acces impliquant de multiples identites
US7715932B2 (en) * 2003-05-02 2010-05-11 Pilz Gmbh & Co. Method and apparatus for controlling a safety-critical process
US8069084B2 (en) 2006-07-14 2011-11-29 Wells Fargo Bank, N.A. Customer controlled account, system, and process
RU2660647C2 (ru) * 2013-05-23 2018-07-06 Росемоунт Инк. Способ и система для удостоверения подлинности изделия
WO2021021064A1 (fr) * 2019-08-01 2021-02-04 Deytek Bi̇li̇şi̇m Mühendi̇sli̇k Sanayi̇ Ve Ti̇caret Li̇mi̇ted Şi̇rketi̇ Système de partage de données

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6212635B1 (en) * 1997-07-18 2001-04-03 David C. Reardon Network security system allowing access and modification to a security subsystem after initial installation when a master token is in place
US6393569B1 (en) * 1996-12-18 2002-05-21 Alexander S. Orenshteyn Secured system for accessing application services from a remote station
US6405203B1 (en) * 1999-04-21 2002-06-11 Research Investment Network, Inc. Method and program product for preventing unauthorized users from using the content of an electronic storage medium
EP1246445A1 (fr) * 2001-03-22 2002-10-02 Nortel Networks Limited Personnalisation flexible des services de réseau

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6393569B1 (en) * 1996-12-18 2002-05-21 Alexander S. Orenshteyn Secured system for accessing application services from a remote station
US6212635B1 (en) * 1997-07-18 2001-04-03 David C. Reardon Network security system allowing access and modification to a security subsystem after initial installation when a master token is in place
US6405203B1 (en) * 1999-04-21 2002-06-11 Research Investment Network, Inc. Method and program product for preventing unauthorized users from using the content of an electronic storage medium
EP1246445A1 (fr) * 2001-03-22 2002-10-02 Nortel Networks Limited Personnalisation flexible des services de réseau

Cited By (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7715932B2 (en) * 2003-05-02 2010-05-11 Pilz Gmbh & Co. Method and apparatus for controlling a safety-critical process
WO2006090392A2 (fr) 2005-02-24 2006-08-31 Rsa Security Inc. Systeme et procede de detection de chevaux de troie procedant a la mystification de dns et de lutte contre ces derniers
EP1866783A2 (fr) * 2005-02-24 2007-12-19 RSA Security, Inc. Systeme et procede de detection de chevaux de troie procedant a la mystification de dns et de lutte contre ces derniers
EP1866783A4 (fr) * 2005-02-24 2014-03-12 Emc Corp Systeme et procede de detection de chevaux de troie procedant a la mystification de dns et de lutte contre ces derniers
WO2007027153A1 (fr) * 2005-09-01 2007-03-08 Encentuate Pte Ltd Systeme d'authentification portable et de commande d'acces impliquant de multiples identites
US7620976B2 (en) 2005-09-01 2009-11-17 International Business Machines Corporation Portable authentication and access control involving multiple identities
US8069084B2 (en) 2006-07-14 2011-11-29 Wells Fargo Bank, N.A. Customer controlled account, system, and process
US10055945B2 (en) 2006-07-14 2018-08-21 Wells Fargo Bank, N.A. Customer controlled account, system, and process
US10366581B2 (en) 2006-07-14 2019-07-30 Wells Fargo Bank, N.A. Customer controlled account, system, and process
RU2660647C2 (ru) * 2013-05-23 2018-07-06 Росемоунт Инк. Способ и система для удостоверения подлинности изделия
WO2021021064A1 (fr) * 2019-08-01 2021-02-04 Deytek Bi̇li̇şi̇m Mühendi̇sli̇k Sanayi̇ Ve Ti̇caret Li̇mi̇ted Şi̇rketi̇ Système de partage de données

Also Published As

Publication number Publication date
WO2003040869A3 (fr) 2004-03-04
AU2002347849A1 (en) 2003-05-19

Similar Documents

Publication Publication Date Title
US20050149759A1 (en) User/product authentication and piracy management system
US7073197B2 (en) Methods and apparatus for protecting information
US6393420B1 (en) Securing Web server source documents and executables
US7996669B2 (en) Computer platforms and their methods of operation
US7426750B2 (en) Network-based content distribution system
US8327453B2 (en) Method and apparatus for protecting information and privacy
US7237114B1 (en) Method and system for signing and authenticating electronic documents
US20070271618A1 (en) Securing access to a service data object
KR20060079139A (ko) 사용후 지불 비즈니스 모델들을 위해 구성할 수 있는소프트웨어 라이센스 관리 시스템
JP2004509398A (ja) ネットワークにわたって配布されるオブジェクトの保護のために監査証跡を確立するためのシステム
Curphey et al. A guide to building secure web applications
WO2001061913A9 (fr) Systeme de distribution de contenu en reseau
KR100621318B1 (ko) 조건들의 검증에 의해 접근과 자원사용을 관리하기 위한 방법
JP3917125B2 (ja) 文書保安システム
Raina PKI security solutions for the Enterprise: solving HIPAA, E-Paper Act, and other compliance issues
Sharma et al. e‐Commerce security: Threats, issues, and methods
WO2003040869A2 (fr) Authentification d'utilisateur/produit et systeme de gestion de piratage
Linkies et al. SAP security and risk management
Smith Object signing in bamboo
Smith Calhoun
Ghosh et al. Web‐Based Vulnerabilities
KR20070022257A (ko) 디지털 라이센스 공유 시스템 및 방법
Jha et al. Implementing Database Security
Triguboff Mobile Commerce Security: Legal & Technological Perspectives
Bugnet et al. Warranty Disclaimer

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR IE IT LU MC NL PT SE SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase in:

Ref country code: JP

WWW Wipo information: withdrawn in national office

Country of ref document: JP