Authentication and Authorization

Cryptographic Key Framework (AACKL)

US Patent 6954740 and Others Pending

(MoneyPINs, MoneyTokens, Authentication and Authorization Tokens, MP Token Library)

 

 

AACKL Principles:

 

1.    Individual stores of cryptographic keys (symmetric and asymmetric)

2.    Individual stores of Limited Time/Transactions cryptographic keys

3.    Individual stores of Limited Time PINs

4.    Individual cryptographic key stores are managed only by individual subscribers (consumers/customers)

5.    Specific key sets can only be retrieved by a validated entity subscriber (financial organization or validated commercial entity)

6.    Individual subscriber access to a key store requires strong authentication

7.    Cryptographic keys can be retrieved/sent only as defined

8.    Cryptographic key sets are mapped to real accounts or batch processes (one or more transactions)

9.    Internal mapping from a single AACKL account to multiple real accounts

10.  Optional interface to multi-account transaction card

11.  Assertion mechanisms communicated to entity subscribers

 

AACKL applications are also published as: MoneyPINs, MoneyTokens, Authentication and Authorization Tokens, MP Token Library

 

 

Introduction

With millions falling victims to high-tech theft, consumers and enterprises need all the protection possible with minor inconvenience to both.  Because many consumer and banking services are now going electronic, the attempts to defraud and steal services and funds are becoming more common.  Any significant accumulation of events that can contribute to an overall reduction of consumer trust will prevent users from migrating from offline processes or cause users to stop using their credit or debit cards.  In some cases, such occurrences may also drive current users back to offline processes or cash only process, which are perceived as being more secured.  In general, online consumer processes provide enterprises with a more economical method of accessing and delivering services to its consumers.  Loosing the ability to migrate consumers online reduces the economic benefits for the enterprise trying to reduce costs.  For enterprises, the inherent lack of trust could result in a lack of revenue, as potential customers are not likely to move online to take advantage of the service.  These considerations need to be part of any business that needs authentication and fraud elimination from their services.  

AACKL Framework

 

AACKL provides authentication and authorization to applications such as check systems, credit cards, debit cards, retail cards, security cards and electronic wallet.  In addition, it can provide authenticated access to software systems, sensitive legal or medical documents, HR or financial information.  In fact, as enterprises are employing the efficiencies of the Internet for e-business with suppliers and customers, AACKL is the simplest logical next step for increased security.  Additionally, AACKL can completely change the market for banking, stock trading, online gaming, membership cards, and security cards with the first easy-to-use  authentication and authorization system, using conventional bank/credit/debit/membership accounts that can affordably reduce the billions of dollars Internet businesses lose annually to fraud.  AACKL instills trust in Internet and Electronic transactions.

Limited Time/Transaction Crypto Keys (LTCK - Password/PIN/Public or Private Key pairs) are used only for a limited time or limited occurrences (once or more) per process, transactions, authorizations, batch of documents, or login sessions.  The dynamic nature of Limited-Time Crypto Key limits the vulnerability, which nonetheless may present a vulnerability window.   However, the risk associated with this vulnerability window can be minimized using options built in the AACKL system.  LTCK Sharing is a concept where LTCKs are maintained by individuals on a centralized individual location (USB memory device, Smart card, Cell phone or wireless PDA) that later can be used with other enterprises in a trusted fashion.  LTCK sharing can help address the major obstacles to deploying authentication to large consumer segments by allowing individual subscribers (consumers) to use LTCKs generated and delivered to enterprises and multiple locations and web sites.  The key concept in the sharing model is an individual centralized LTCK service infrastructure responsible for storage and provisioning of stores of LTCKs and for the validation of a multi-factor authentication associated with the store (pool) of LTCKs.  In this model strong authentication is only required at the IAE, which is the Individual Authentication Enterprise level.  Only the IAE need to optionally deploy a second-factor strong authentication to individual subscribers (member users) accessing the IAE.  An enterprise using AACKL-IAE services does not necessarily need to employ strong authentication infrastructure with its customers, because the IAE application will.  Most consumers are familiar with the concept of logging in with a username password.  Typically, a consumer (individual subscriber) will log in to the IAE application installed on a hardware security key as one of the following:

·         Smart card

·         Cell phone or wireless PDA

·         Biometrics device

 

After authentication individual subscribers can access their LTCK store and could either generate more or delete old stores of LTCK.  The LTCK stores include symmetric passwords and public-private key pairs.  The individual subscriber could also elect to use master keys/passwords that could be designated as a master authorization to generate run time LTCKs.  LTCK stores can be shared between accounts or delegated to specific accounts as designated by the individual subscriber.

AACKL Applications:

• Checks, debit and credit card authorizations
• Online Debit Card PINS Changes
• Bank Internet Payment System (BIPS)
• SDML Signed Document Markup Language
• FDML Financial Services Markup Language
• SAML Security Assertions Markup Language
• eCheck - Electronic checks
• Controlled protected Internet payments
• Money transfer
• Online payments
• Online gaming
• Retail membership cards
• Security Cards
• Anonymous payments
• e-Cash  and electronic wallet
• Software authentication
• Document authentication
• Application logins – Single Sign-on Applications
• Electronic gift certificates
• Internet auctions
• One-time key systems

 

 

Individual Authentication Enterprise (IAE)-  MoneyPINS Framework Application

The application resides in a Biometric USB Device and has the following features:

 

·         LTCK Synchronization with Financial Enterprises using SSL and web communications

·         Automatic LTCK generation and entry for current applications (Passwords or PINs)

·         In-memory data protection in addition to AES encryption of stored data

·         Support for sending keystrokes (auto-type) to windows

·         Automatic login’s to applications and web-sites

·         Automatic PIN or Credentials entry.

 

 

AACKL Interfaces - Smart Card/PDA/Cell Phone

The cards used by AACKL are a combination of both magnetic stripe/bar code and proximity cards, providing a seamless technology bridge, with one common output.  Enhanced application cards include MIFARE compliant cards. MIFARE cards come equipped with a wealth of features, including securely separated files for complex AACKL applications, mutual authentication and data encryption. PDA or Smart Cell Phones are devices that could be programmed and have electronic communication capabilities.

 

The figure above shows an example of an individual subscriber interaction with the IAE.  The individual subscriber opens the IAE (Individual Authentication Enterprise) application.  To authenticate himself to the IAE application, he will enter his username, his associated password, and other requested information.  The IAE will validate the username and password against the IAE membership store, retrieve the second factor authentication method and then verify the second factor authentication data (Biometrics, Certificate, Smart Card, etc).  Upon successful authentication the individual subscriber can view his IAE Accounts and their respective LTCKs stores.  He also can generate more LTCKs or cancel LTCKs stores.  The individual subscriber can also generate private-public key pairs and retrieve the corresponding private keys associated with the stores of public keys. The individual subscriber could also elect to use master keys-passwords that could be designated as a master authorization needed to generate run time LTCKs.  The individual subscriber with the cooperation of the financial enterprise (e.g. Bank) which accounts he is using can also configure his IAE profile to enable further authentication.  After generating LTCKs stores the individual subscriber can choose one of the LTCKs delivery methods as following:

 

1. Have the IAE enter the required data to login screens or web applications
2. Print lists of LTCKs to be used.
3.  Input the LTCK into a smart card or other electronic device (PDA, Cell Phone..)
4. Have the IAE application Interface directly with check clearing system, credit card system or other systems.

 

 

The delivery of the IAE LTCK’s stores to enterprises (banks, clearing agents, merchants) can comprise of several methods:

 

1. Connect to the enterprise system using SSL.
2. Connect to the enterprise system using any other electronic means.
3. Transmit data wirelessly.

 

 

The figure below shows an example of transaction authentication session.  The individual subscriber performs a transaction and submits to a merchant an IAE account number (or his IAE card), an account selection designator + LTCK and optional additional details.  The LTCK submitted could be a used to generate run time OTP or one time token.  The transaction can include a Check, Credit Card, Money Transfer, Electronic Check, Debit, Bank Transfer, etc.  Transactions can also include non-financial transactions as login requests, software registration verification and electronic authorizations. The transaction verification process is done using the pre-existing means of the enterprise or application.

AACKL Framework Implementations

 

AACKL implementations are also published as: MoneyPINs, MoneyTokens, Authentication and Authorization Tokens, MP Token Library

 

 

MoneyPINS/MoneyTokens Implementations

 

Credit/Debit Cards Transactions

An individual subscriber account holder commonly orders an item and provides the merchant with a credit card or an IAE account number, amount to authorize and a LTCK.  LTCK lifetime can include 1 or more transactions or a date range.  The methods for posting LTCK are listed herein:

·         LTCKs can be attached on the credit card slip by sticking a preprinted label

·         LTCKs can be handwritten on the credit slip

·         LTCKs can be transmitted using a mobile electronic device (e.g. smart card, PDA)

 

The merchant can use the information to verify the individual subscriber’s authenticity and to verify that the account holder can in fact use the credit card to execute the particular transaction. If an unauthorized person obtains the credit card number, this person cannot use the credit card number in placing unauthorized transaction requests without obtaining the LTCKs available only to the account holder.  If an IAE account is used, real account information is not revealed and the real account is selected by the IAE based in the key input.

 

 

 

Credit Card or Bank Checks Transactions using Mirrored Conventional Accounts

An account holder provides a merchant or a financial organization with an IAE account number, the amount to authorize and a LTCK. The IAE account number has its mirrored real account number (CC or bank account) and real account information is not revealed to the public.

 

·         The Bank or the Merchant sends transaction details to the IAE (or directly to the card company or bank)

·         The IAE authenticates the details and applies a LTCK to that specific transaction

·         The authorization is sent to the bank or the card company for approval via the Internet or other electronic means

 

 

Bank Check Transactions Using Computing Hardware (Hard Copy/Wireless)

A customer commonly uses check-writing software to print several checks at a time.  The checks contain an LTCK derived number for each check.  The LTCKs are retrieved by check writing software, which uses the same algorithm and a private/public key specific to the application and setup in the IAE application. The algorithm can include the content of the AMOUNT, DATE and PAY TO THE ORDER OF fields.  The generated LTCK derived number can be printed on the PC field or Check Number Field on the MICR line.  The bank, in order to verify the check can use the account number, LTCK and other optional personal data.  In addition, the AMOUNT, DATE and PAY TO THE ORDER OF fields, which are used in combination with the LTCK, are verified.  If an unauthorized person obtains your checkbook, the unauthorized person cannot use the checks without obtaining the LTCK and the bank’s counter check presentations.  Written signatures are not commonly used to verify checks except for over the counter presentation.  This described method is one several modes of operation that can be used with bank checks and the IAE application.  The LTCKs can be stored in the IAE for each check. Or more effectively, LTCKs, in a specific case can use a private key for batches of checks.

 

 

 

  

 

Checks with NO Computing Hardware (Written Hard Copy)

An account holder commonly writes several checks and provides different merchants or banks with LTCKs for each check.  Several methods can be used to post the LTCK:

·         LTCKs can be attached on the check by sticking a preprinted label

·         LTCKs can be handwritten on the check

·         LTCKs can be provided from a mobile electronic device (e.g. smart card, PDA)

·         LTCKs can be transmitted from the IAE 

 

This method is one of several modes of operation used with bank checks and the IAE.  In this specific method, LTCK need to be generated by the IAE for each check or use a generated  asymmetric key for a group of checks. 

 

 

Electronic Check Payments Using Positive Balance Account

Money is kept in an IAE account.  It can use either one of the following methods for settling the payments:

1.      Charging the consumer's credit card for maintaining the required balance.

2.      Debiting a checking account for the required balance.

3.      The Consumer sends a check to create a positive balance in his account, and any authorized payments will be deducted from this account.

After a member consumer approves a transaction, by giving a merchant an IAE account and an LTCK, the merchant is paid by the financial institution responsible for the IAE account.

 

Retail Membership Cards

The IAE card contains a bar code or a magnetic strip readable at the retail outlets. The barcode and the magnetic strip contain the IAE account number.  When a retailer issues a card, he uses the IAE account and submits to the IAE application the retail account used.  The retailers can use the IAE account number or its own account number.  When the retailer scans the IAE card, they can either use the IAE account directly or with a combination of a conversion table.  LTCK are mostly not needed, except for using the card for financial transactions.

 

Electronic Check Payments

Consumers can pay for products or services with an electronic check by selecting a corresponding IAE account.  The consumer can give the merchant his IAE account number and a LTCK.  Either the consumer or the merchant can initiate the transaction.  The IAE application transmits the required data to a financial institution’s secure transaction server for posting.  At settlement time, the financial institution initiates a debit to the consumer's checking account.

 

 

Electronic E-Mail Payments

The IAE can use e-mail to inform the receiver that a payment has been made.  It uses the consumer’s IAE account or a financial institution real account with a combination of a posted LTCK.  

 

Electronic Money (Wallet)

Magnetic card contains a 'purse' in which LTCKs are held electronically.  The card also contains security parameters that protect transactions between the Merchant and the financial institution.   The consumer's money is deposited in his IAE account using any conventional deposit methods.  The merchant inserts the Wallet card and the consumer gives him an LTCK.   The financial institution’s server will authorize the transaction if a balance exists, and update the consumer’s balance.  The financial institution then delivers the cash to the merchant. 

 

 

 

Electronic Gift Cards

Magnetic card contains a gift amount, which corresponds to the amount in the IAE consumer’s account.  When a merchant issues a gift card a new IAE account is created using the card account number, amount, security parameters and several LTCKs.  The card contains security parameters that protect transactions between the Merchant and the financial institution.    When a consumer performs a purchase, the merchant inserts the card and the consumer gives him a LTCK. 

 

Software Authentication

Software companies can secure their software distribution and the installation licenses using an IAE account.  Each license will have its corresponding LTCK record.  AACKL SDK can be used to interface with the IAE and verify licenses using Internet connections.

 

Document Authentication

Legal and other enterprises can secure and authenticate their distributed documents using an IAE account.  Each enterprise can have an IAE account and a set of LTCKs.  AACKL SDK can be used to interface with the IAE and authenticate documents.  In addition to the above method, the IAE can contain a private or public key (LTCK key) used in combination to create a document hash or document signature.

 

Message Validation

Enterprises can authenticate and encrypt distributed messages using AACKL.  Each message can have its associated LTCK.  AACKL SDK can be used to interface with the IAE and authenticate messages using Internet connections.  In addition, the IAE can provide a private key (LTCK) used create a message hash and encrypt the message.  An associated public key can be distributed to decrypt the message

 

 

 

Conclusion

Strong authentication is an important component for addressing threats such as phishing, account hijacking, and associated identity theft and fraud.  Though strong authentication by itself may not completely solve the problem, it should be considered one of the foundations for a comprehensive solution around consumer-identity protection.  Phishing is the greatest threat to this system. However, phishing can be controlled and its associated risks are smaller than other implementations. AACKL is a major solution that can be used to help address authentication for consumer applications as well for enterprise users.  AACKL is also a solution that can provide authorization for financial transactions in addition to authentication.  As discussed, several implementation models could exist for using AACKL.  Each implementation model is uniquely qualified for its applicability to specific use cases ranging from financial transactions to more complex authentication and authorization solutions.  The advantages of AACKL are that the models discussed could help reduce the cost and complexity of deploying strong authentication while reducing fraud and abuse.  Only the IAE need to optionally deploy second-factor strong authentication to member users accessing the IAE (added value for strong authentication).  An enterprise using AACKL services does not necessarily need to employ strong authentication infrastructure for its customers, because the IAE application will.  The advantage for consumers is that they can use their single IAE account/card and store of authenticated LTCKs to access various accounts, applications and systems, which can have lower levels of authentication strength and infrastructure.

 

Definitions

 

1. Authentication — the process of electronically establishing an acceptable level of Confidence, an identity of a claimant

2.    Individual subscribers – member users including consumers, customers, commercial entities or end-user applications.  Individual subscriber presents a credential purporting to be a particular identity who uses an AACKL to perform and authorize a transaction or a process

3.    Entity subscriber - Financial organization, merchant, or validated commercial entity

4. Credential — Digital documents used in authentication that binds an identity or identification attribute to a token and IAE account
5. Identity — a unique identifier of a person that includes a legal name and a minimum set of attributes needed to make the identity unique
6. One/Limited Time or Limited Transactions Cryptographic key (LTCK) - Password/PIN/Key— A value used to control cryptographic operations, such as decryption, encryption, signature generation or signature verification.  It can also uniquely identify a transaction, a document, or an entity in combination with an account number.  The LTCK is used in a combination of set of AACKL IAE actions including financial transactions.  The LTCK in AACKL does not mean it is used only once, but can be used at least once or more in a defined time period.
7. Asymmetric keys - Two related keys, a public key and a private key that are used to perform complementary operations, such as encryption and decryption or signature generation and signature verification.
8. Private Key - The secret part of an asymmetric key pair that is typically used to digitally sign or decrypt data.
9. Public Key -The public part of an asymmetric key pair that is typically used to verify signatures or encrypt data
10. Symmetric key - A cryptographic key that is used to perform both the cryptographic operation and its inverse, for example to encrypt and decrypt, or create a message authentication code and to verify the code.
11. Transport Layer Security (TLS) - An authentication and security protocol widely implemented in browsers and web servers. TLS is defined by [RFC 2246] and [RFC 3546]. TLS is similar to the older Secure Socket Layer (SSL) protocol and is effectively SSL version 3.1.
12. Tunneled password protocol - A protocol where a password is sent through a protected channel.
13. Digital Signature - An asymmetric key operation where the private key is used to digitally sign an electronic document and the public key is used to verify the signature. Digital signatures provide authentication and integrity protection.
14. Financial Enterprise — any financial or commercial organization
15. IAE — Individual Authentication and Authorization Enterprise or interchangeably an AACKL IAE  (MoneyPINS Application)

 

 

Keywords: Authentication, Authorization, Authentication Assurance, Credentials Service Provider, Cryptography, Electronic Authentication, Electronic Credentials, Electronic Transactions, Identity Proofing, Passwords, Authentication Keys, Authentication Tokens, MoneyPINS, MoneyTokens, MoneyKeys, Money Tokens, Money Keys, Token Library, Key Library.

 

 

 

 

 

 

Written by: Albert Talker

 

 

Summary of Vulnerabilities - Online and Offline Transactions

1.    PKI infrastructure shortcomings (see PKI Shortcoming: http://verycrypt.com/PKI_Shortcomings.htm)

2.    Net Passport shortcomings (see Net Passport Shortcoming: http://verycrypt.com/Net_Passport_Shortcoming.htm)

3. Checking-account theft is the fastest-growing financial fraud affecting consumers and is now second only to credit card theft.  Banks don’t use the same kind of fraud detection software on checking accounts that they use on credit card transactions to spot suspicious purchases.  In practice, they cannot use the same schemes as credit card fraud detection software mainly because authorization is not verified at the same time the checks are presented.
4. Flaws in Internet Explorer and the Microsoft software.  Thieves exploited security flaws in Internet Explorer and the Microsoft software that runs big Internet servers.
5. Internet related vulnerabilities as traffic sniffing, parameter tampering, cross site scripting, cookie poisoning, SQL injection, backdoor debug options, stealth commanding, forceful browsing and buffer overflows.
6. Hackers (including inside hackers) breaking into the Web servers of large trusted companies and steal personal and financial data.
7. “Phishing” and Pharming.  Phishing is the behavioral trick of leading consumers to a Web site that resembles one they normally use.  Phishing attempts designed specifically to steal bank information.  The trend neatly follows a sharp rise in so-called phishing e-mails, which attempt to steal consumers' user names and passwords by imitating e-mail from legitimate financial institutions.  Pharming is a machine level redirection of a browser to a hacker’s Web site.  In both cases, when consumers enter their information, even after using strong second factor authentication, criminals collect the data that can then be used to access consumers’ online accounts.
8. Trojan horse programs, keyloggers, and Man-in-the-middle attacks.  Trojan horse programs and keyloggers steal passwords and account information.  Such secret malicious programs, which experts say are more widespread than many realize, could be the cause of up to half the account takeovers.  Man-in-the-middle attacks occur with network sniffers, sniffing communication packets and also occur in the form of keyboard logging, when a rogue piece of code captures a password the consumer has entered into his or her computer.   As public terminals become increasingly prevalent, a rogue piece of code that can sniff at consumers’ usernames, passwords, and other information is more likely prevalent.
9. Unauthorized demand drafts.  Demand drafts were designed to accommodate legitimate telemarketers who receive authorization from consumers to take money out of their checking accounts.  But the potential for abuse is high.  Not only do they not require a signature, but also they require no action by the checking account holder.
10. Forged digital proof of payment.  Congress passed the legislation authorizing the change last year. The Check Clearing for the 21st Century Act cleared the way for the simplified process by allowing digital images of checks to be deemed legal representation of payment — so-called substitute checks can now be presented to companies as proof of payment.   There are many ways to forge digital images and make them look as the original checks.  Just viewing several counterfeit notes can easily convince many laymen on the powers of digital imaging.
11. Forged/Stolen credit cards.  There is a time gap for notification, when a credit card is stolen or misused which enables thieves to use the card to its limit.
12. Forged checks and payments.  There are many ways for thieves to access your checking account.  For example, forging your checks, counterfeiting checks, wire draft to withdraw money from your account, or produce unauthorized payment.
13. Unauthorized debit transactions.  Debit cards were designed to accommodate legitimate consumers who wish to pay directly using money out of their checking accounts.  However, the potential for abuse is high.
14. Multiple cards for each bank or credit card and accumulation of cards, when lost in a purse the person loose all his privacy with all the accessibility given by these cards. 
15. Eavesdroppers observing authentication protocol runs for later analysis
16. Financial organization insider abuse
17. Authentication process costs
18. Unauthorized use
19. Repudiation of registration
20. Stolen identity
21. Imposter of a claimed identity
22. Impersonation of a claimed identity

 

 

Shortcoming and Risks of eChecks, FSML, SAML and SDML

SDML is a message format structure that allows an entity such as a bill payer to provide an electronic document whose author and integrity can be authenticated. SDML documents may be digitally signed using public key cryptographic signature and hash algorithms.

FSML is FSTC-developed Financial Services Markup Language, which defines the specific document parts needed for electronic checks, the tags which identify check-specific data items, the semantics of the data items, and processing requirements for electronic checks.

SAML is Security Assertions Markup Language.  SAML was approved by the Organization for the Advancement of Structured Information Systems (OASIS).

Risks –

1.    PKI infrastructure shortcomings (see PKI Shortcoming: http://verycrypt.com/PKI_Shortcomings.htm)

2.    No key recovery mechanisms can jeopardize the proper operation

3.    Unauthorized use of digital keys

4.    Stolen digital keys

5.    Insider Abuse

6.    New targets of electronic attacks

7.    A single private key could unlock much or all of the data of a company or individual.

8.    Large scale coordinated operation

9.    Requires many CA’s

10. Deployment of secure infrastructures

Complexity –

1.    PKI Infrastructure is an extraordinarily complex system, with numerous new entities, keys, operational requirements, and interactions. The system is far more complex and difficult to implement than the basic encryption functions themselves.

2.    Coordination and Management issues with all financial organization, the Feds and customers

Economic Cost –

No one has yet described, much less demonstrated, a viable economic model to account for the true costs of such infrastructure encompassing all banks, and customers.

Processing and Computing Power –

Private/Public key encryption requires a larger digital storage space and requires computer processing power in the order 100-2000 times over regular encryption.