Authentication in Modern Computing Environments

1
Authentication in Modern Computing Environments

• Moti Yung, Columbia University

2
Authentication

• We have been very successful in Cryptography in
  designing authentication
• Kerberos building on the NS model
• IPSEC building on various authentication protocol
  works (I had some contributions in Crypto 90
  paper)
• SSL/TLS (I had some contributions suggesting the
  server only public key model in Crypto 85)

3
User Authentication starts at the User

• While, IPSEC, SSL/TLS, etc. are major
  authentication tools, in reality, user
  authentication starts at the user level (web
  computing, user sign-on, etc.). Thus, PASSWORD is
  the most prevalent tool.
• Many issues in authentication are open and simple
  concepts have been left out and ignore
  advancements in computing environments.
• Phishing for example, exploits the look-alike of
  a phishing site and original bank site (uses
  social engineering).

4
The Three Traditional Factors Evidence in
Authentication

• Something you know
• Password / PIN
• Knowledge-based authentication Answer
• Something you have
• One-time password token
• Smart card / USB token Signature/ mobile phone
• Something you are / can do
• Biometrics Fingerprints, voice

5
Observe!!

• All the factors are bilateral (usersystem)
• Observe No other parties are involved.. !!!!
• But in modern computing environment the user is
  rarely alone (user and PC). There is Internet of
  people and machines around!
• Fundamental Issue Can we use this fact?

6
What we Claim

• The 3-factor is based on bilateral relationships
  typical of time-sharing machines
• In modern Internet time we can exploit other
  computing devices and users in designing factors.

7
From FFIEC 2005 Guidelines

• Regarding user authentication
• "The agencies consider single-factor
  authentication, as the only control mechanism, to
  be inadequate for high-risk transactions
  involving access to customer information or the
  movement of funds to other parties.

8
? Password Not Enough

• US Government asked for compliance by year-end
  2006
• US banks were required to enhance one-factor
  authentication.

9
Authentication in real life comes in many
shapes and forms

• User Type (enterprise employee, client)
  flexibility, usability
• System Setting (internal, open commerce, Internet
  banking)
• Type of Action (Financial/ non-financial/
  Financial value)
• Parties Trust relationships I am not even
  talking about two-way auth., phishing, etc.

10
ISSUES

• Most authentication issues are a result of (1)
  poor computing and networking infrastructure that
  has no security (2) ultimate solutions are
  costly (3) usability and business needs are not
  necessarily security-friendly (4) financial
  transactions are controlled by risk management
  not elimination of all fraud (5) users are not
  the most trusted entity.

11
User Authentication Model
User
Agent
Resource
Evidence
Auth.Protocol
Auth. Factors
Users Devices

• Forward Authentication Steps
• User and Users Devices present Evidence to
  Agent demonstrating possession of Authentication
  Factors
• Agent conveys Evidence to Resource in
  Authentication Protocol

12
Variations on the Model

• Local authentication User authenticates directly
  to resource, without agent
• e.g. Log into PC Unlock smart card
• Authentication server User authenticates once
  to authentication server, which relays ticket or
  authentication assertion to resource
• e.g. Kerberos Identity providers
• Validation server Resource relies on separate
  validation server for part or all of
  authentication
• e.g. Credential federation

13
Describing an Authentication Mechanism

• An authentication mechanism is a ceremony
  involving
• Selected authentication factors
• Particular evidence about those factors and a
• Specific protocol for conveying the evidence

Ceremony by Carl Ellison / Jesse Walker
protocol model involving human users, their
systems, machines, etc. .
14
In This Talk

• I will cover two scenarios
• User of on-line banking with no special
  authentication device (no smartcard, usb token,
  etc.)
• User in an organization with a separate hardware
  token that lost/ forgot the token

15
Casual User a client of a bank

• Financial Institutes have consumer who engage in
  transactions
• Consumer usage of hardware tokens/ smartcards in
  their many banks is a problem (in the US market
  and others, less of a problem in Asia)
• Not all transactions need high level of
  authentication

16
Idea

• Many ways to authenticate the
• users computing environment,
• user, knowledge of the user
• User mobile device, etc.
• Users computer IP address/ A cookie in browser
  as examples
• If not the usual IP address then extra auth call
  the users mobile phone, or ask him from a list
  of questions.

17
This means

• If a user gave away his/ her usual credentials
  like password, account number and all details to
  a Phishing email attack in an attackers Phishing
  site
• Then Still, the security is not lost for
  off-line Phishers (only man in the middle
  remains and needs more efforts)

18
Approach

• Increase Authentication Factors (using the
  computing environment, knowledge about user) for
  flexibility and usability and minimizing extra
  efforts of consumers in particular no need for
  hardware token devices etc. USE PASSIVE FACTORS
  of the environment
• Now collecting credentials by faked sites
  (regular phishing) may not be enough for
  attackers and they will attack elsewhere...

19
Second Idea

• Connect authentication method to risk-value of
  the transaction based on model of fraud (adaptive
  authentication). Use more authentication factors
  as needed.
• This will balance the needs of authentication
  against usability and will make reactive
  authentication based on risk level as the bank
  manages it.

20
Possible Approach I

• Risk Assessment Tool to
• Monitor Transactions
• Keep track of bad transaction
• Run a model of transactions performed by
  fraudster (from various sources) and learn
  their behavior as in anti-fraud systems in general

21
Possible Approach II

• Authentication Tool
• Assess a given transaction against model and
  determine level of risk
• Based on risk decide let transaction go on or
  invoke extra authentication methods
• Overseeing Tool
• Coordinate actions across different locations,
  from different sources (global effort)

22
Overall secure the user

• Based on PC device and user profile, assesses
  risk of all transactions and invokes additional
  authentication for risky transactions. Invisible
  to majority of users most of the time
• Above is increased by action based on learned
  fraud pattern.
• This tools and methods are employed in industry
  (RSA is a leader in this space)

23
What is achieved

• New methods to assess risk in transactions
• It is working in a world of active and adaptive
  attackers
• It requires constant learning of model of
  attacks/ fraud (even across various banks)
• Integration of credential methods and risk based
  authentication/ protection is an adaptive
  solution that can be merged with risk management
  tools.

24
First Scenario Morale

• Exploit users machines as factors
• Have graded authentication levels taking into
  account risk vs. applicability/usability

25
Second Scenario

• User in an organization a company where users
  are in groups, and there is well defined
  relationships among users (organizational chart).
  Based on paper published in ACMs CCS 2006

26
Primary vs. Secondary Methods

• Credentials or credential processing unit may not
  be available
• - our motivating example user forgets
  her authentication token, or the biometrics
  reader is out of service
• Users need an a backup alternative to log into
  the machine productivity and usability may be
  more important than security alone!

27
Backup Methods

• Common Alternatives
• - E-mail (the security relies on email security
  an having an alternative account)
• - Life questions (security in answer entropy,
  over time degradation)
• - In an enterprise call a help-desk (social
  engineering backdoor) typically the user and the
  help-desk operator do not know each other

28
Social Relationships and Authentication

• Break also here the bilateral constraint at the
  very basic factor level!
• Relying on Somebody You Know isan age-old
  mechanism for humanity (people used introduction
  letters in old times), a relatively new tool for
  user authentication .

29
Further

• The notion has been used to rely on other
  credentials based on human relationships
• - Credentials are trusted (in PGP SPKI/SDSI
  PKIs (relying on web of trust), Trust Management
  Systems and reputation systems based on social
  relationships
• - Here How to employ the notion as a factor
  by itself (formalize the notion and employ in
  ceremonies)

30
Steps I

• We Formalize a Model for claiming correctness and
  security of authentication ceremonies, based on
  simple probabilistic assumptions about the
  ability of Entities to present Factors. The model
  use simple probabilistic assertions
• It has helped in verifying and defining the
  goals, and reviewing the design of the protocol
  and assumptions about components

31
Steps II

• Our goal was exploiting social relationship in a
  simple, usable way, so we designed and
  implemented (assuming formal properties of
  communication channels)
• We then look at systems and attack variations
  beyond the formal model, to assure the factor has
  right properties for deployment in an extended
  systems setting

32
Basic Idea Voucher Systems

• Users authenticate themselves to the system via a
  ceremony session where they simply present their
  factors
• -- Example User presents password and, for
  example, a token-code the one-time value for
  evidence that his token (device) outputs for the
  session but can also be a signature from his USB
  token

33
Basic Idea Voucher Systems (ii)

• If a user does not have his token (device), then
  there are pre-assigned group of other users who
  may vouch for that user. Namely, there is an
  alternative ceremony by which a user contacts a
  helper who interacts with the system and aid
  the user in its authentication.

34
Define properties

• Correctness and Security properties will be
  derived from differences between the probability
  of the correct claiming by presenting a factor
  X(x) and that of an impersonation attempt,
  namely X(y), where y is not x.
• Correctness defines the fact that a honest entity
  can claim its own identity at all times with very
  high probability (1-epsilon)

35
Security Properties

• We assume the system tries to prevent
  impersonation with some high probability.
• We also assume independent logging/ audit trails
  (not under the user control) and thus detection
  of small probability bad events is possible.

36
The properties

• Formalizing the events, probabilities,
  interactions, system components and ceremony
  actions we now realized that Security has to do
  with two properties
• Prevention Impersonation (by dishonest parties)
  has low probability from basic assumptions about
  factors and success of events.
• Detection If the low probability event do occur,
  the log reveals it if checked w.v.h. probability.

37
Voucher System

• We have users presenting passwords and
  token-codes as the basic factors in their primary
  authentication sessions
• If token device is not available, we allow users
  to get helped by other users vouching for them
• (I will not further use the formal notation, if
  interested see the paper)

38
Voucher System Enrollment

• For a vouching to take place, the helper Harry
  has to establish relationships with the user
  Alice, thus there is an enrollment process where
  Harry meets Alice. and the mechanisms/ policy
  by which help will be asked are established as
  well (i.e., Alice may call Harry from her office
  phone or mobile phone).

39
Rules

• Which users can help whom is a system policy (in
  an enterprise it can use the organizational chart
  to determine the relation).
• Users are carefully notified of their
  responsibilities (e.g., getting an independent
  email from the system) and the policy regarding
  vouching e.g., You must identify by phone the
  voice of the user asking for help and verify the
  caller id..
• Policy is driven by probability of identification

40
Voucher System Ceremony

• 1. Alice Contacts Harry out-of-band call, say,
  asking for help
• 2. Harry authenticates Alice verifying her
  identity (system must assure the method gives
  high enough probability p1)
• 3. Harry authenticates to the System Using a
  specific and separate authentication session
  where he is designated as a helper.

41
Continuation

• 4. Harry obtains a Vouch-code the system
  verifies that Harry and Alice are indeed a
  designated helper-user pair, if so a user
  specific large enough value is given as a
  vouch-code (so it is hard to guess, only with a
  small probability p2)
• 5. Vouch-code is delivered to Alice
• 6. Alice enters vouch-code It is delivered to
  the system in a session from Alices own
  computer.

42
Voucher System (cont.)

• 7. System authenticates Alice Checks the factors
  (e.g., password), and checks the vouch-code
  against a database of recently issued codes.
• 8. Alice chooses Temporary Password If step 7 is
  successful the system accepts from Alice a
  temporary password, to be useful for the day, say
  (this neutralizes the fact that Harry knows the
  vouch-code, and makes it easier for Alice to sign
  on during the day based on memorizable value).

43
Continuation

• 9. Logging Events are audited (audit is
  available and under the systems control) and
  notifications are sent to involved parties.

44
What is achieved

• We show correctness
• We show Security (low probability of
  impersonation based on basic probability of
  getting the token code, vouch-code, and
  password), considering all attacks we extracted
  from the system and its structure --
  Outsider, --Unregistered Helper, --Helper against
  User, and --User against Helper
• We show detection of all bad (low prob.) events
  in the logs.

45
Note

• The formal tools were used to reflect carefully
  on requirements, assumptions, needs and design
  decisions (interactive design and analysis,
  moving between protocol and claims). The final
  claims of properties validates the design under
  the assumptions (see the paper)

46
Further Pragmatic Considerations Beyond the
Model

• Always in design of systems there is residual
  analysis left due to the gap between the formal
  setting and the deployment setting since the
  model only captures part of the actual setting
  we considered such issues here

47
Pragmatic Considerations

• - Investigated pragmatic channels for delivery of
  requests/ codes e.g., how to discourage the
  helper from using the users machine in the
  session! (keyboard-logger on user machine can get
  helpers password!)
• Social engineering issues e.g., how to design
  the system so that undesirable channels are not
  easy to employ (asking for help over a gmail
  account on something that looks like the users
  real name)

48
Even Further Voucher Demo

• Simple Web-based Application
• Performed also usability study with 12 users.

49
Second Scenario Morale

• Exploit multi-user relationships for
  authentication
• Have backup methods since authentication is not a
  goal but rather a means.

50
Conclusions

• Formally looked at non-bilateral factors of
  authentication
• Demonstrated using passive factors of computer,
  mobile phone, etc. and also introduced the notion
  of vouching in user authentication, again
  breaking the strictly bilateral nature of
  authentication factors
• Designed simple working tools for risk based
  authentication by mixing factors
• Designed vouching tool for emergencies

51
Conclusions II

• Security considerations formally and carefully
  in the model getting what we need to achieve
  (using probability), and further issues in the
  systems setting (where components are not
  perfect)
• Extensions of both risk-based authentication and
  vouching are possible , e.g., in a vouchcode or
  risk-level mode where user gets restricted
  privileges, richer policy
• Further exploiting the notions and the tools is
  open.
• Morale Always room to think about new simple yet
  highly effective issues, concepts and solutions
  (non bilateral factors in this case and their
  analysis for a specific factor)

52
Further

• As computing environment evolve we cannot and
  should not stick by old paradigms (here that
  there are three basic factors)
• When looking beyond bilateral relationships there
  are plenty more factors.

53
Thank you!