Risk Analysis for Access Control Delegation and Remote Unlock in Smart Buildings

1
Risk Analysis for Access Control Delegation and
Remote Unlock in Smart Buildings

• Nikita Borisov, Ragib Hasan, Sundeep Reddy

2
Agenda

• Access Delegation
• Remote Unlock

3
Access delegation

• Current Situation
• Andover
• No concept of groups/roles
• LDAP servers has
• Access to the university system
• Has groups like csGrads, undergrads, faculty etc
• Has information on TA/RA appointments
• Can support constraints, rules etc.

4
Adding new people

• LDAP server has different objects information on
  students, appointments, grad/undergrad etc. and
  is synchronized with the university system
• At the start of the semester, a PHP script
  creates list of newly added students and related
  room permissions
• The list is sent to TSG, and imported into
  Andover system

PHP Script creates entries
Personal Data Importer adds entries to Andover
LDAP server
Entries to be added
University System
Imported into Andover
5
Adding access
Space Allocation List
Professor
3. Find out if the person in charge of room
agrees to allow access
TSG
2. Looks up Space allocation or recall from memory
1. Send Request to TSG for access to door
4. Update Andover System
Student
6
Problems

• Large work load for TSG
• Only two people actually update the list
• Start-of-semester workload about 2 person-days
• Manual maintenance of request logs (email, text
  file)
• Access policy, room ownership not precisely
  specified in the system TSG has to rely on
  personal knowledge or space allocation list
• Possibility of conflicts
• Possibility of errors
• Auditability

7
Problems (cont)

• Inconsistencies between LDAP server and Andover
• Manual requests for access update Andover, but
  not LDAP
• Inconsistent naming, ID,
• Cleanup
• Difficult to know when to remove access
• Entries in Andover dont have groups and dont
  represent reason for access

8
Delegation

• Define room owners
• Professor can have ownership of lab
• Access may be controlled by defining groups
• Request for room access goes to room owner
• Room owner grants permission, access granted
  immediately, the message goes to TSG and put in a
  queue
• At the end of each day, TSG approves or rejects
  the access
• Automated conflict check (example Number of
  people with access to lab, exceeds capacity)

9
Benefits

• Reduced load on TSG (time spent is less)
• Explicit ownership constraints (TSG doesnt need
  to have informal way of knowing who owns a door,
  dont have to educate new employees, admins can
  go on vacation)
• Reduced delay
• High delays in summer
• Smaller chance of mistakes
• Confusing who owns door
• Confusing 2 doors net ids

10
Risks

• Complexity of doors/multi door access
• Group maintenance overhead (if group used) (what
  if people leave groups)
• Internet connectivity (of door access) can cause
  compromise of door access, or subvert access
  control scheme
• Lack of human check?
• Availability?

11
Issues

• Will groups help?
• Large or small groups?(large groups such as
  (faculties, grads, undergrads) or smaller groups
  such as (security research, database) ?)
• Auditability
• Need for human check
• Expiration of access
• Visitor cards

12
Remote Unlock

• Allowing people to unlock door locks via the
  Internet or smart phones
• Currently done manually by TSG

13
Current Unlock Scheme
Locked out person
1. Go to TSG for opening door
TSG
2. Verify ID, verify person has access to door
3. Accompany person to door, use TSGs card to
open it, or open it remotely, monitor whether
room state changes
14
Remote Unlock Benefits

• Remote unlock reduces the load on TSG, because
  any person who has locked himself out can go to a
  room anytime. Also, no third party authentication
  (like showing the personnel a drivers license, or
  other type of id) or personal verification is
  needed.
• Easier recovery /reduced time
• Unlocking can be done at night or during breaks.
• Remote access -- A professor may provide access
  to a grad student even if she is out of state.

15
Remote Unlock Risks

• Timing attacks
• When is the room unlocked? Immediately after
  request? If unlock done over the Internet from
  some machine, anyone standing in front of the
  door can go in before the actual requestor
  arrives.
• Timeouts?
• No presence requirements How do we ensure the
  person requesting the unlock is actually in front
  of the room? How do we make sure the person
  really entered?
• Idea can the door lock be used for other ways of
  authentication?

16
Remote Unlock Risks

• Authentication via Bluestem only?
• Is that sufficient/strong?
• What other methods can be used?
• Human in the loop
• Do we need to verify such requests for abuse?
• Main door
• Can we allow remote unlock of the main door?
• Unauthorized persons
• If there is a problem, anyone without an I-card
  can be able to enter.

17
Remote Unlock Risks

• Multi door access

18
Issues

• Policy
• Who can unlock door? The door owner, or anyone
  with access to a door
• Should we allow unlock at all doors? Are some
  doors sensitive enough to have no remote unlock?