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 moving online and 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. In some cases, such occurrences may also drive current users back to offline processes, 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.
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_Shortcomings.htm)
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
One Time Crypto Keys (OTCK - Password/PIN/Public or Private Key pairs) are used only once per process, batch of transactions, single transaction, single authorization, batch of documents, or login sessions. The dynamic nature of One-Time Crypto Key limits the vulnerability to a single instance, 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. OTCK Sharing is a concept where OTCKs are maintained by one centralized enterprise that later can be used at other enterprises in a trusted fashion. OTCK sharing can help address the major obstacles to deploying authentication to large consumer segments by allowing individual subscribers (consumers) to use OTCKs generated from the same centralized enterprise, at multiple locations and web sites, and by allowing individual subscribers to view the OTCKs that have already been used and for which purpose. The key concept in the sharing model is a centralized OTCK service infrastructure responsible for storage and provisioning of stores of OTCKs and for the validation of a multi-factor authentication associated with the store (pool) of OTCKs. In this model strong authentication is only required at the CAE, which is the centralized level. Only the CAE need to optionally deploy a second-factor strong authentication to individual subscribers (member users) accessing the CAE. An enterprise using AACKL-CAE services does not necessarily need to employ strong authentication infrastructure with its customers, because the CAE enterprise will. The concept of requiring a physical device that generates a single-use dynamic password at the consumers’ level is not used in this model and is not the scope of AACKL. However, the centralized level may use similar concept to generate stores of OTCKs. Most consumers are familiar with the concept of logging in with a username password. Typically, a consumer (individual subscriber) will log in to the CAE- centralized service, managed by the first authentication factor—usually, a username and password in its own (using SSL connection). To accommodate a stronger authentication one or more of the following suggested authentication methods could be used (second and third factors):
After
authentication individual subscribers can access their OTCK store and could
either generate more or delete old stores of OTCK. The OTCK 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 OTCKs. OTCK stores can be
shared between accounts or delegated to specific accounts as designated by the
individual subscriber.
AACKL Applications:
Government benefits: Central Key Recovery
System
AACKL (MoneyPINS) Account Cards
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.
This model implies that each enterprise acting as a Centralized Authentication Enterprise will need to deploy an authentication scheme, which will authenticate individual subscribers and other enterprises subscribers requesting authentication and access to OTCKs stores. The CAE will be able to offer both Identity and Attribute authentication. Attribute authentication is achieved by using the CAE links with the financial enterprises (or other enterprises).
The figure above shows an example of an individual subscriber interaction with the CAE. The individual subscriber has requested to initiate a session with the CAE over SSL connection (SSL –proven safe and reliable method). To authenticate himself to the CAE, he will enter his username, his associated password, and other requested information. The CAE will validate the username and password against the CAE membership store, retrieve the second factor authentication method and then verify the second factor authentication data (Token, Biometerics, IP address, Certificate, Smart Card, etc). Upon successful authentication the individual subscriber can view his CAE Accounts and their respective OTCKs stores. He also can generate more OTCKs or cancel OTCKs 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 OTCKs. The individual subscriber with the cooperation of the CAE (e.g. financial enterprise) which accounts he is using can also configure his CAE profile to enable tiered authentication (e.g. smart card interface or biometrics devices interface based of transaction amount levels). After initiating a session with the CAE and generating OTCKs stores the individual subscriber can choose one of the OTCKs delivery methods (optionally using Transport Layer Security-TLS) as following:
1. Print or Email lists of OTCKs to be used for the next batch of transactions.
2. Print to scratch pads or scratch paper lists of OTCKs
3. Download with optional encryption the formula or the selected OTCKs to a smart card or to a magnetic card writer.
4. Download, to an originating PC, OTCKs stores, private keys, and optional formulas required for generating OTCKs. For example, this process can be initiated when check printing is needed.
5. Interface with check clearing system, credit card system or other systems.
The figure above shows an example of transaction authentication session. The individual subscriber performs a transaction and submits to a merchant a CAE account number (or his CAE card), an account selection designator + OTCK and optional additional details. The OTCK 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 as follows:
** The
individual subscriber referenced above can be interchangeably referenced also as
a financial enterprise **
Analysis:
Because the CAE is sharing only the CAE account and an OTCK and not the real account or the individual subscriber’s Information, AACKL system entails a relatively simple liability focused more on individual subscriber’s use of the OTCK for authentication and authorization. In this AACKL model, each transaction originating enterprise needs only to establish a business and operational relationship with the CAE, meaning that it is simpler to implement. The CAE can specify the framework and rules for authentication and communication. This model enables rapid creation of strong-authentication communities and can help the deployment of individual subscribers’ strong authentication.
OTCK delivery methods to the individual subscriber from the CAE could be one or more of the following:
* OTCK delivery methods optionally could use Transport Layer Security-TLS
This OTCK
Wallet leverages next-generation mobile devices such as Java cell phones, smart
cards, and personal digital assistants (PDAs). In this model, the mobile device becomes an
"OTCK wallet” that can contain multiple OTCKs (symmetric keys or private keys)
and optional credentials. In this model the party acting as the
centralized authentication and authorization enterprise (CAE) initially
authenticates the individual subscriber. Upon successful authentication, the CAE can
assert the individual subscriber’s identity and then send “OTCK Wallet” data for
storage on the mobile device. The primary advantage of this model is that
the technology to enable this model is relatively easy and well understood and
hardware devices are already available in the market. However, unlike as
in other models discussed, the mobile device can optionally store individual
subscriber’s credentials that can be shared with other enterprise
subscribers.
This factor results in complex liability and trust models that need to be
negotiated between the participants.
Strong authentication at the centralized level and lax authentication at the individual subscriber transaction level is one of the core principles of AACKL. Shared OTCKs that are selected and generated by the individual subscribers is another core concept where OTCKs are issued to the individual subscribers by one centralized enterprise, which can later be used at other enterprises in a trusted fashion. The individual subscriber generated store of OTCKs could be used as keys for non-repudiated transactions and for authorization and authentication. Some consumers (individual subscribers) may initially shy away of this technology. However, when authentication and fraud elimination is the end result, consumers could understand the need for such technology.
AACKL is a patented solution that prevents fraud by empowering merchants and financial institutions to automatically perform authentication of the consumer’s true identity and authorization.
AACKL is a secure e-commerce method performed without revealing financial or personal information. No one can use your bank or credit card account without your authorization. You can pay anywhere just by giving a CAE account and an AACKL OTCK. You can sign your checks with a non-repudiated key that reflects the values of your check (nobody can forge or copy or use your checks). You can authorize and pay for a transaction, using your credit card just by giving an AACKL number that only you can give and generate. Imagine paying using a smart card that gives timed OTCKs, which are as good as a bank note. When using AACKL, your financial data is safe. Merchants just get your AACKL account number and an OTCK. When authorizing credit card transactions the vendor uses your AACKL account (CAE account), while the authorization is submitted to the issuing bank with your actual credit card number stored in your CAE account profile. Vendors alternatively, could receive your address information only when you authorize them to do so using an authorizing token.
An individual subscriber account holder commonly orders an item and provides the merchant with a credit card or a CAE account number, amount to authorize and an OTCK. The methods for posting OTCK are listed herein:
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 OTCKs available only to the account holder. If a CAE account is used, real account information is not revealed and the real account is selected by the CAE based in the key input.
An account holder provides a merchant or a financial
organization with a CAE account number, the amount to authorize and an OTCK. The
CAE account number has its mirrored real account number (CC or bank account) and
real account information is not revealed to the public.
Then the merchant and the financial organization process the transaction in the normal way. Any further transactions (ACH, check delivery, etc) can be performed later at settlement time.
This described method is one several modes of operation that can be used with bank checks and the CAE. The OTCKs can be stored in the CAE for each check. Or more effectively, OTCKs, in this case a private key, can be used to generate batch or 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 OTCKs for each check. Several methods can be used to post the OTCK:
This method is
one of several modes of operation used with bank checks and the CAE. In this specific
method, OTCK need to be stored in the CAE for each check or a asymmetric key for
a group of checks.
Money is kept in a CAE 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 a CAE account and an OTCK, the merchant is paid by the CAE. The merchant can receive the payment from the CAE by a check, or a direct deposit into his checking account.
Retail Membership
Cards
The CAE card contains a bar code or a magnetic strip readable at the retail outlets. The barcode and the magnetic strip contain the CAE account number. When a retailer issues a card, he uses the CAE account and submits to the CAE the retail account used. The retailers can use the CAE account number or its own account number. When the retailer scans the CAE card he can either use the CAE account directly or with a combination of a conversion table. OTCK are mostly not needed, except for using the card for financial transactions or to gain entry.
Electronic Check
Payments
Consumers can pay for products or services with an electronic check by selecting a corresponding CAE account. The consumer can give the merchant his CAE account number and an OTCK. Either the consumer or the merchant can initiate the transaction. The CAE transmits the required data to a secure transaction server for posting. At settlement time, the CAE system initiates a debit to the consumer's checking account via the Automated Clearing House (ACH) and then transfers collected funds to the merchant's account. The CAE system notifies merchants of failed debit attempts, including “Not Sufficient Funds” returns.
Electronic E-Mail Payments
The CAE can use e-mail to inform the receiver that a payment has been made. It uses the consumer’s account for the money. It can use either one of the following methods for settling the payments:
The Consumer sends a check to create a positive balance in his account at the CAE and any authorized payments will be deducted from his account. The merchant can receive the payment from the CAE by a check, or direct deposit into his checking account.
Magnetic card
contains a 'purse' in which OTCKs are held electronically. The card also
contains security parameters that protect transactions between the Merchant and
the CAE.
The consumer's money is deposited in his CAE account using any
conventional deposit methods. The merchant inserts the Wallet card and the
consumer gives him an OTCK. The CAE server will authorize the
transaction if balance exists, and update the consumer’s balance. The CAE then
delivers the cash to the merchant. The merchant can receive the payment from the
CAE by a check, or a direct deposit into his checking account.
Magnetic card contains a gift amount, which corresponds to the amount in the CAE consumer’s account. When a merchant issues a gift card a new CAE account is created using the card account number, amount, security parameters and several OTCKs. The card contains security parameters that protect transactions between the Merchant and the CAE. The consumer's gift money can be kept with the CAE or it can be kept with the merchant. When a consumer performs a purchase, the merchant inserts the card and the consumer gives him an OTCK. The CAE will authorize the transaction if balance exists, and update the consumer’s balance. The consumer can view his balance and transactions on the CAE using a master password issued at the time he gets his card.
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.
Authentication and non-repudiation of documents (or a set of financial
documents) can be done using a private/public key set which has an associated
public/private key stored on the CAE. Interchangeably, a one time symmetric
secret key can be used which has it counterpart key stored on the CAE
server.
SDML is FSTC-developed Signed
Documents Markup Language. It 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 a
private key and hash algorithm. The associated public key can be retrieved
from the CAE.
SAML is Security Assertions Markup
Language. SAML
was approved by the Organization for the Advancement of Structured Information
Systems (OASIS).
Authentication and non-repudiation of documents (or a set of financial
documents) can be done using a private/public key which has an associated
public/private key stored on the CAE. Interchangeably, a one time symmetric
secret key can be used which has it counterpart key stored on the CAE
server.
Intranet or Client/Server Authentication Middleware
AACKL CAE can implement a Centralized password
management, single sign-on (SSO) and authentication
management infrastructure. The CAE can implement a
ticket-based, peer entity authentication service and access control service
distributed in a client/server network environment. The CAE server in
this application is the authorization engine, supporting a number of
authentication methods to provide flexibility to all organizations using this
CAE server.
The server will also store all information about an organization’s users,
groups, resources, applications, login parameters and access control rules. Password
synchronization between applications will not be needed as applications will
process a ticket-based authentication.
Software companies can secure their software distribution and the installation licenses using a CAE account. Each license will have its corresponding OTCK record. AACKL SDK can be used to interface with the CAE and verify licenses using Internet connections.
Legal and
other enterprises can secure and authenticate their distributed documents using
a CAE account.
Each enterprise can have a CAE account and a set of OTCKs. AACKL SDK can be
used to interface with the CAE and authenticate documents using Internet
connections.
In addition to the above method, the CAE can contain a private or public
key (OTCK key) used in combination to create a document hash or document
signature.
Enterprises can authenticate and encrypt distributed messages using AACKL. Each message can have its associated OTCK. AACKL SDK can be used to interface with the CAE and authenticate messages using Internet connections. In addition, the CAE can provide a public key (OTCK) used create a message hash and encrypt the message. The private key can be distributed to decrypt the message
MP Token Library -Implementation
In this
application the CAE is used to store the following:
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 CAE need to optionally deploy second-factor strong authentication to member users accessing the CAE (added value for strong authentication). An enterprise using AACKL services does not necessarily need to employ strong authentication infrastructure for its customers, because the CAE will. The advantage for consumers is that they can use their single CAE account/card and store of authenticated OTCKs to access various accounts, applications and systems, which can have lower levels of authentication strength and infrastructure.
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