AccessControlModeling

From Noisebridge
Jump to: navigation, search

Copy-pasta from online discussion May 8, 2014

From https://pad.riseup.net/p/FO9XJQtyL1Xc


With keys and keycodes:

Current Future Keypad or lock at gate blocks entry to space Lock at gate and keypad at door block entry to space Keypad is active at all times Keypad is active during "late" hours Physical key allows entry to building and space Physical key allows entry to building, but keypad blocks entry to space Keycode allows entry into building and space Keycode ONLY allows entry into space, not building Visitor needs to be buzzed in Visitor needs to be buzzed in and welcomed at the door Intruder can shadow a building entrant Intruder can shadow a building entrant A key or keycode is needed to let oneself in A key AND keycode is needed to let oneself in Elevator is not a backdoor beyond single auth Elevator allows bypass of keypad auth Key can be duplicated and not revoked Key can be duplicated and not revoked Keycode can be shared, but revoked Keycode can be shared, but revoked

Bold: during late hours Benefit of separating lock and keypad - Semblance of 2-factor auth - Robotically enforced "members-only" hours


Consider alternatives:

   RFID > keycode in terms of uniqueness
   


With RFID (1) and keycodes (2):

Current Future Keypad or lock at gate blocks entry to space Sensor at gate and keypad at door block entry to space Keypad is active at all times Keypad is active during "late" hours Physical key allows entry to building and space Fob allows entry to building, but keypad blocks entry to space Keycode allows entry into building and space Keycode ONLY allows entry into space, not building Visitor needs to be buzzed in Visitor needs to be buzzed in and welcomed at the door Intruder can shadow a building entrant Intruder can shadow a building entrant Member needs a key or keycode to let themselves in Member needs a fob AND keycode to let themselves in Elevator is not a backdoor beyond single auth Elevator allows bypass of keypad auth Key can be duplicated Fob (probably) cannot be duplicated, and can be revoked Keycode can be shared, but revoked Keycode can be shared, but revoked

Bold: during late hours Benefit of RFID at gate over key at gate: - fob can be revoked, key cannot Benefit of RFID at gate over current: - Semblance of 2-factor auth - Robotically enforced "members-only" hours

RFID + Keycode = two-factor. indeed! -nthmost


With keycode or key (1) and RFID (2): Current Future Keypad or lock at gate blocks entry to space Keypad or lock at gate and sensor at door block entry to space Keypad is active at all times Keypad is active at all times (not applicable) RFID is active at late hours Physical key allows entry to building and space Key allows entry to building, but sensor blocks entry to space Key allows entry into building and space Key ONLY allows entry into building, not space Keycode allows entry into building and space Keycode ONLY allows entry into space, not building Visitor needs to be buzzed in Visitor needs to be buzzed in and welcomed at the door Intruder can shadow a building entrant Intruder can shadow a building entrant Member needs a key or keycode to let themselves in Member needs a key or keycode AND fob to let themselves in Elevator is not a backdoor beyond single auth Elevator allows bypass of fob auth (not applicable) Fob (probably) cannot be duplicated, and can be revoked Key can be duplicated Key can be duplicated Keycode can be shared, but revoked Keycode can be shared, but revoked Lock and keypad require occasional maintenance Lock, keypad, AND RFID sensor require occasional maintenance

Bold: during late hours Benefit of RFID at door, over RFID at gate: - RFID sensor less likely to be tampered with (and if so, it's by hackers, not sleepers) ^ ^ ^ my thinking as well. - no need to dismantle existing infrastructure ...plus above benefits (~line 44)






Current: keys cannot be trusted - can this be built around? can this weakness be repositioned as a strength?

"keys cannot be trusted" ... meaning what? They can be trusted to work. "keys cannot be trusted" - above says "member needs a key", however there is no proof that having a key means you are a member. perhaps "posession of a key is not an indication of trust" is a better way to say it. (AHH makes sense) furthermore, we teach lockpicking at nb, not having a keyd doesn't mean I can't get in. the current key entry should not be trusted anyway. ^ we need representation in this discussion from folks who are actively duplicating/distributing keys <-- false. we don't need representation from people who are stealing in order to talk about ways to stop people from stealing. if there's a cultural history to this... any changes will require cultural buy-in or they'll be circumvented. (see: idealism vs. rayc)

"not having a key doesn't mean I can't get in" <-- that's a great argument for keeping the keycode at the front door.  :)

"Shared" is just another word for "duplicated".

"Stealing" is a strange word to use for the NB key. would you prefer "abuse of the space"? So you're saying that "folks who are actively dup'ing keys" are abusing the space? That includes Mitch. I'm saying there's no way to prove it. There is no way to revoke a key. Mitch is good people. How many sleepers have keys? Hint: you can't possibly know.

Yeah I don't think this conversation gets anywhere in terms of Threat Modeling. The key is not a form of security. End of story. ok, so why move the panel to the top of the stairs? what does that solve? if the key isn't security, and the panel isn't security, what's up? Um, i am still suggesting RFID at the top of the stairs. we're on the same page then. I think it should be RFID at both, or RFID + code for two-factor. the keys should die. (see below comparison table.) Oh that's the opposite of the way we're currently talking about it -- the below table is RFID at bottom, right? yes So I'm arguing for:

   * don't change how the front gate operates AT ALL
   * install RFID thing at top.

cool, I'll make a table for that too

"keys should die" <-- not gonna happen. And pointless. this should be rethought. what are the reasons they can't die? <- other tenants in building = hackers in other countries have them The Legend Of Noisebridge. The fact that Mitch uses them for outreach. Other tenants. Oh, also, the fact that the way we have our door set up now required a lot of social investment in the landlord. I.e. we will burn social capital changing it up to our liking AGAIN. just saying, the current Legend of Noisebridge is that you can't leave anything valuable there And that's not likely to change, not unless we lock up Member Shelves as well That's a TOTALLY different attack surface and threat model.


ok, so here's an option: phase out the keys in a creative way. ie maybe keep the keyhole, but turning the key doesn't unlock the door. ie it causes the buzzer to go or somehing, or a screen to display a message saying the keys are ending, or something that rewards the person for having and using a key but lets them know that it is no longer the way in. there's got to be a way to make the keys go away. they are the root of the security problem, anything else we do here is just patching. ^ again, other tenants in the building. re-issuing four keys is not as big a job as maintaining >100 unknowns from what i understand, we don't know or have any contact with the other tenants in the building. changing the keys themselves shouldn't be a big deal. changing the way the locking mechanism and front gate work is just... i dunno, rude, or something, without their buy-in. I'm sorry, what? That's factually inaccurate. We have contact with the other tenant (the second floor). <- i stand corrected :) Alright -- anyway see also my "social capital" statement above. I think we're saying the same thing, basically -- changes to the door == spending a lot of social capital. (Important issue right now because the landlord is already a little upset about the Electrical Situation.)


I like "phase out keys" because it's unlikely to work. Good luck with that.

  • love* your attitude! :D

I'm becoming famous for it. Still haven't earned my Troll Badge though.  :( --nthmost famous, yes.

In all seriousness, "phasing out keys" is just as bad as changing the lock. There are people coming to NB who got a key years ago. They're supposed to come try out their key that they've been saving for years only to find that it doesn't completely work?


(sorry in advance for this) - is this the elephant in the room? absolutely. :) ___________.__ __ \_ _____/| | _______ _______ _/ |_ ___________

|    __)_ |  | _/ __ \  \/ /\__  \\   __\/  _ \_  __ \
|        \|  |_\  ___/\   /  / __ \|  | (  <_> )  | \/

/_______ /|____/\___ >\_/ (____ /__| \____/|__|

       \/           \/           \/                   
       absolutely, though you'll note that there's a key access on the elevator as well. hacking a relay to make the button for the thrird floor only work when a circuit is active isn't rocket surgery
       

^ ^ ^ we talked about this in #security-wg on Slack, definitely an issue in terms of Real Security. how so? what do you mean by "definitely an issue" There is already a frame for a gate within the elevator lobby, FYI. --yesac (does he mean the elevator lobby in 1F or 3F? if 3F, that's [potentially] a big win) if he means 1F he better mean 2F too... <-- THIS

meaning that even if we lock down the top door, people using the Elevator can use it to get in. total bypass. So if you guys have a plan for an Elevator locking mechanism -- one that keeps in mind the fact that it makes NB accessible to wheelchairs -- go for it. ok, so you understand how a relay works, right? keylock switch also? just a keyhole where turning the key either makes or interrupts a circuit? same thing. probably a little more expensive, might be $50-$70 in parts to put a reader on the elevator. hardest part imho would be getting the data to a central place for auth.

i think we have to design around the current working of the elevator. it's been designated a no-hack area. of course, we could get it re-classified. <-- and THIS

Personal tools