Improving the Safety and Practicality of Authorization Technology Using LOAF

1
Improving the Safety and Practicality of
Authorization Technology Using LOAF

• ACM Workshop on Digital Identity Management
• Takumi Akahoshi and Naohisa Komatsu
• Department of Computer Science and Engineering,
• Waseda University
• Manabu Okamoto and Michio Shimomura
• NTT information Sharing Platform Laboratories,
• NTT Corporation

2
Table of Contents

• BackgroundMotivation
• Friend of a friend authorization model
• Proposed method
• Evaluation of practicality and safety
• Conclusion and future plans

3
Background

• Authorization in SNS

Social Networking Services (SNS) are gathering
much attention, and are getting huge numbers of
users.
Access control by user relationships is
important feature of SNS
E.g. I can show only friend photograph. open
the profile to all users. only the friend can
see my diary.
Access control between users in SNS

• friend
• same community
• friend of a friend

the access control by a variety of user
relations is being put to practical use.
4
Motivation

• Friend-of-a-friend access control

friend-of-a-friend access control is actually
allowed. ? However, only between same SNS.
friend-of-a-friend access control will be
necessary to allow between different SNS.
We propose an effective method for
friend-of-a-friend access control between
different SNS, using OpenID as a User ID, with
its global ID property
5
OpenID
Type of proxy authentication method. A user ID is
coded in URI or XRI format. By creating a single
OpenID, users can log in easily to all web sites
that support OpenID
(1) Log in with OpenID
RP
(4) Redirect
(6) Redirect
OpenID-supporting site
User
E.g. Choix?LiveJournal
(5) Password input and authentication
(2) Download an OpenID URL
(3) Request encryption key and encrypt ID
OP
OpenID Authorization server
User URL host
E.g. Yahoo! Japan, OpenID.ne.jp
E.g. http//www.openid.ne.jp/user-a/
6
Friend of a friend authorization model

• Friend-of-a-friend access control(basic approach)

?No.
?want to see Bobs photo
OpenID authentication server(OP1.com)
?is the ID(a) friend ?
Alice
?a request to authorize Alice
User F1
Bob
Friend List
Friend List
ID(a)
friends
ID
Access
User F2
F1 http//OP1.com/f1/ F2 http//OP1.com/f2/ F3
http//OP2.ne.jp/f3/ F4 http//OP3.org/f4/
Bob
Friend List

?the ID(a) is my friend !
Photo sharing site(RP)
?the ID(a) is not in friend list
OP2.ne.jp
OP3.org
F3
F4
Inquire with other OPs based on OpenID URL.
Friend List
Friend List
Other OpenID authentication servers

• cause many requests
• a load of the system will be heavy

Send a request to the friends OP. If accessing
party is a friend of a friend, accept access
7
For improving practicality

• LOAF(List of all friends)

Friends ID http//openid.com/user/
Users friend list

• Represented in Bloom Filter
• preserves anonymity.
• doesnt requires much resources
• and will not affect whole systems.
• false positives are possible.

Hash functions
010001
ORed
Friend list LOAF
it is possible that users are able to send his or
her friend list to another users with keeping the
users anonymity.
using accessing partys or friends LOAF, we
could check whether accessing party is friend of
a friend efficiently.
8
FOAF(friend-of-a-friend) Discovery method

• Apply LOAF

? want to see Bobs photo
OpenID authentication server (OP1.com)
?ID(f2) will be a friend of ID(a)
Alice
Bob
? a request to authorize
User f1
Friend List
Friend List
Friend
ID
AccessID(a)
F1 http//OP1.com/f1/ F2 http//OP1.com/f2/ F3
http//OP2.ne.jp/f3/ F4 http//OP3.org/f4/
User f2
Bob
AccessID(a)
Friend List
RequestID(a)

? the ID(a) is not in the Friend List
?is ID(a) your friend?
Photo sharing site(RP)
?Alice is my friend
LOAF(a)
?send LOAF
User f3
User f4
Alice
Friend List
Friend List
OpenID authentication server (OP4.ne.jp)
OP3.org
OP2.ne.jp
OpenID authentication server
This method could reduce the number of requests
to friends
9
FOAF(friend-of-a-friend) Discovery method

• Identifying cases of LOAF possession

A
OP
Bob
Alice
Friend List

ID(a)
ID(f1)
ID(f2)


Other OP
accessing party provides his/her own LOAF
Not use LOAF
C
D
OP
OP
Bob
Bob
Alice
Alice
ID(f1)
LOAF(f1)
ID(f1)
LOAF(f1)
LOAF(a)


ID(a)
ID(f2)
LOAF(f2)
ID(f2)
LOAF(f2)
Other OP
ID(a)




Other OP
user has his friends LOAF
Combination of B and C
10
Evaluation

• Evaluation of practicality
• Appropriate LOAF size for operation
• Number of inquires from user to friends
• Evaluation of safety
• False positive rate when the accessing party
  impersonates

?Evaluate based on data of mixi, the largest SNS
site in Japan and supported OpenID
11
Appropriate LOAF size for operation

• Evaluate LOAF size based on mixi

Information of mixi
Number of all user15,000,000
conditions
Number of friends 1000 (fixed) the false
positive rate 1
Avarage number of friends21
Number of friend limited 1000
False-positive-rate
? about 1
LOAF size (bytes)

• Appropriate LOAF size is about 1200bytes

12
Number of inquires
Number of inquires to OP of friends
Number of accesses depends on LOAF false-positive
rate
Accesses from spammers are much higher than from
legitimate users.
length of bit array
False-positive rate
number of hash functions
The length of the bit array is fixed to 1200bytes.
Patterns B, C, and D were effectively reduced to
zero.
13
Appropriate LOAF size for operation

• An effect on the system

Patterns C and D
Pattern B

• Its necessary to retain LOAF of all users

• User need
• not retain LOAF

• Using 1200 bytes as the size of LOAF,
• the total size of all LOAFs stored in the system
  (OP) would be about 378Gbytes.

accessing party provides LOAF.

• It should have no significant effect on the
  system when passes LOAFs through the network.

• By using the LOAF, it is possible to reduce the
  number of requests to the OPs of friends
  dramatically.
• ? but no significant difference on patterns B,
  C, and D.
• storing all friends LOAF (in patterns C and D),
  
• we must consider the total size of all LOAFs in
  system.

14
Evaluation

• Evaluation of practicality
• Appropriate LOAF size for operation
• Number of inquires from user to friends
• Evaluation of safety
• False-positive rate
• when accessing party impersonates the LOAF

15
Evaluation of safety

• Threat arising from use of LOAF

Ex-Girlfriend attack
If someone obtains a LOAF, he can find out
whether IDs are in the LOAF or not.
Marc Canter attack
If all bits of a Bloom Filter are set to one, all
ID can pass through the filter
Dictionary attack
When someone created OpenIDs using a dictionary
and register to LOAF. He can falsify LOAF.
OpenID http//www.openid.ne.jp/takumi123/
Domain (Limited)
Name
Me Too attack
An access party can impersonate another person by
presenting another persons LOAF as their own.

16
Threat arising from use of the LOAF

• Ex-Girlfriend attack

If someone obtains a LOAF, he can find out
whether IDs in the LOAF or not.
B and D When the user attempts access, there is
possibility that the LOAF will be passed to a
malicious user. If so, the malicious user can
get users LOAF easily.
C It is not vulnerable to attack. Because
only LOAFs from friends are used, and they are
passed between trustworthy systems
Is it safe?
ynot vulnerable to attack
nvulnerable to attack
17
Threat arising from use of the LOAF

• Marc Canter attack, Dictionary attack, Me Too
  attack

• A malicious accessing party provides a fake LOAF
  
• and he impersonates another friend of a friend.

B OP uses a LOAF from the accessing party, so
if he provides a fake LOAF or another users
LOAF, he could impersonate friend of a friend.
?it is necessary to check that the LOAF is
accessing partys own.
C It is not vulnerable to attack. Because only
LOAFs from friends are used and they are passed
between trustworthy systems.
D A LOAF from the accessing party is used, but
it retains the friends LOAF, so the filter is
applied again. Because of this, it is not
vulnerable to attack
Is it safe?
ynot vulnerable to attack
nvulnerable to attack
18
Vulnerability in FOAF Discovery method

• Threat vulnerability in each case

• Patterns that involve accepting LOAFs from, or
  passing LOAFs to untrusted Bobre vulnerable to
  attack.

19
Summary and future plans
Summary

• A friend-of-a-friend access control between
  different SNS, use of OpenID as the user ID.
• We applied LOAF to the above method. Therefore,
  we could reduce a number of requests to OPs of
  friends.
• We have evaluated practicality and safety of
  proposed method.

Future plans

• examine updating LOAF in case the user retains
  LOAF of all friends.
• verify the reliability of LOAF in case the user
  uses LOAF from accessing party.

20
(No Transcript)
21
Appropriate LOAF size for operation

• An effect on the system

Patterns C and D

• It is necessary to retain LOAF files of all
  users.
• Using 1200 bytes as the size of LOAF,
• the total size of all LOAFs stored in the system
  (OP) would be about 378Gbytes.

Pattern B

• User need not retain LOAF, accessing party
  provides LOAF.
• It should have no significant effect on the
  system when passes LOAFs through the network.

Number of users
LOAF size
Number of friends
LOAF size that one user has.

• By using the LOAF, it is possible to reduce the
  number of requests to the OPs of friends
  dramatically.
• ?but no significant difference on patterns B, C,
  and D.
• storing all friends LOAF (in patterns C and D),
  we must consider the total size of all LOAFs in
  system.

22
Vulnerability in FOAF Discovery method

• Threat vulnerability in each case

• Patterns that involve accepting LOAFs from, or
  passing LOAFs to untrusted Bobre vulnerable to
  attack.

23
Vulnerability in FOAF Discovery method

• Threat vulnerability in each case

Patterns B and D are vulnerable to attacks,
because they are provided LOAFs from, or passing
LOAFs to untrusted users.
24
Appropriate LOAF size for operation

• An effect on the system

Pattern B

• User need not retain LOAF, accessing party
  provides LOAF.
• It should have no significant effect on the
  system when passes LOAFs through the network.

Patterns C and D

• It is necessary to retain LOAF files of all
  users.
• Using 1200 bytes as the size of LOAF,
• the total size of all LOAFs stored in the system
  (OP) would be
• about 378Gbytes.

LOAF size
Number of friends
Number of users
LOAF size that one user has.
25
Evaluation
practicality

• By using the LOAF, we can reduce the number of
  requests to the OPs of friends dramatically.
• ?but no significant difference on patterns B, C,
  and D.
• when a single LOAF passes through networks, the
  system has small load.
• storing all friends LOAF (in patterns C and D),
  we must consider the total size of all LOAFs in
  system.

Considering to update LOAF, pattern B may be the
most appropriate.
safety

• Patterns that accepts LOAFs from, or passes
  LOAFs to untrusted Bobre vulnerable to attack.

Only LOAFs passed between trustworthy systems are
used. Pattern C may be the most appropriate.
26
Overview of LOAF
users frind List represented in Bloom Filter
?conceived by Burton H. Bloom in 1970, a
space-efficient probabilistic data structure that
is used to test whether an element is a member of
a set
Hash function
(number of hash functions )
A bit array with all bits set to zero
(length m )
Registration process
Authentication process
LOAF
Hash functions
Hash functions
ID that want to authenticate whether to be in the
LOAF
1
Friend List
http//OP.com/f1/ http//OP.ne.jp/f2/
http//OP.net/fn/
http//OP.ne.jp/v/
1


?number of friends n
1
Positions indicated by the k indexes are set to 1

• If any of the bits are zero, this ID is not in
  LOAF
• If all k bits are set, this ID is assumed to be
  in LOAF
• ?it can produce false positives

Does all ID in the Friend list, and ORed is LOAF