Risk Analysis for Access Control Delegation and

Remote Unlock in Smart Buildings

Nikita Borisov, Ragib Hasan, Sundeep Reddy

Agenda

Access Delegation Remote Unlock

Access delegation

Current SituationAndover:

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.

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

LDAP server Entries to be added Imported into

Andover

PHP Script creates entries

Personal Data Importer adds entries to Andover

University System

Adding access

TSG

ProfessorSpace Allocation

List

Student

1. Send Request to TSG for access to door

2. Looks up Space allocation or recall from memory

3. Find out if the person in charge of room agrees to allow access

4. Update Andover System

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

Problems (cont)

Inconsistencies between LDAP server and AndoverManual requests for access update Andover,

but not LDAP Inconsistent naming, ID, …

CleanupDifficult to know when to remove accessEntries in Andover don’t have groups and don’t

represent reason for access

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)

Benefits

Reduced load on TSG (time spent is less) Explicit ownership constraints (TSG doesn’t need

to have informal way of knowing who owns a door, don’t 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

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?

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

Remote Unlock

Allowing people to unlock door locks via the Internet or smart phones

Currently done manually by TSG

Current Unlock Scheme

TSG

Locked out person

1. Go to TSG for opening door

2. Verify ID, verify person has access to door

3. Accompany person to door, use TSG’s card to open it, or open it remotely, monitor whether room state changes

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.

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?

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.

Remote Unlock: Risks

Multi door access

Issues

PolicyWho can unlock door? The door owner, or

anyone with access to a doorShould we allow unlock at all doors? Are some

doors sensitive enough to have no remote unlock?