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 University System LDAP server Entries to be added 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 don’t have groups and don’t 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 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

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 TSG’s 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?