Open source deadbolt lock

Why?

I’m not physically changing the lock, so our crappy Kwikset is one. It’s made of plastic, so it’s possible to yank it off to pry at the lock. ESP RFID just reads the UID of the cards as well. Mostly hyperbole since it’s secure enough for me. :slight_smile:

Right okay. Well, in fairness, you’re not a lockmaker :slight_smile:

1 Like

You are being a little tough on yourself

Yeah, Maybe 2 Mins to defeat

Do you have windows???
2 Secs to defeat

It is still a physical barrier, and a lowly thief will likely look for an alternative / easier means of entry. They may check out your backdoor :wink:
or
See window comment above

If they see electronics, rather than “hack your system”;
See window comment above

Also
If not the window, they may deploy the Size Eleven tool :hiking_boot:

Do you see the theme?

Locks only keep honest people out!

Your lock project is a means of convenience for you, and it looks like it is doing that job perfectly :+1:

Exactly :exclamation:

4 Likes

Would it be possible to use a spark 1 or a flexMN to activate the SHS-3321?

spark 1 is iso15693 so no there… and flexMN cannot emulate a 4 byte mifare classic, so only older shs-3321s with older firmware will work, or you can downgrade your firmware…

@Devilclarke did you ever get you hands on one of the gimdow lock actuator units?

Curious

So what your saying is a flexMT will work then?

Yes, yes I did really neat unit the problem I see it is there are alot of small parts and other bits that don’t make it ideal for the community project.

So I will be starting to put my home system together soon. My plans involve a combination of online and ‘offline’ servers/sensors. Do you have any good pointers from your experience putting together and refining your systems?

It has been 6 months that I am waiting to move to my new place (I got stuck with the worst solicitors in human history).

So currently my systems are all in boxes and breadboards waiting to be unpacked, assembled and only then end-to-end tested.

I also “borrowed” a little from some secure facilities I’ve dealt with, so I’m thinking about re-writing some of the bits so I can actually make a shareable comprehensive post about it. :sweat_smile:

These are some of my thoughts/plans on it:

  • I’m setting the lock mechanism on the strike plate side, not on the door.

  • I won’t rely on batteries. the system will be hooked to a no-break battery and to power mains.

  • I’m still thinking how to set up a reliable notification system for every time my no-break kicks in

  • all the installation sits inside the walls

  • reader will be set up flat to the external wall, behind the wall-paper (I’m moving into an apartment building, so there is wallpaper. You could use a very thin layer of plaster possibly for a house).

  • The door and handle will remain unmodified, as to not draw unwanted attention. (The more secure your house looks, the more it attracts crooks who believe if you spend that much in security it’s because you have valuables…)

  • I’m using a raspberry pi zero, but if you want a more professional look you could go for arduino instead. My choice for raspberry comes partly because I already had a lot of the GPIO code ready (“borrowed”), partly because my only means of access to it once inside a wall will be ethernet.

  • If I can’t find v1.31 of the raspberry zero (best revision of the board without wifi), I get the newer versions (W) and fuck the wifi module. I also fuck up the BT module just in case.

  • If going for raspberry and you want to use a newer model, I strongly advise against anything stronger than a Pi2. This is because you seriously won’t need the performance gain from 3 onwards, and such stronger processors also require a much steadier power source. Therefore any drops on current will cause it to reboot. Older models can work on less stable current with less of an issue.

  • Raspberry uses GPIO to control a relay switch to trigger the door plate.

  • When buying the wall plate, make sure you buy the right model: there are “off closed” and “safe - off open” models. I obviously chose off-closed because don’t want my door unlocked if power goes down.

  • I’m considering if to use a mechanical or mechanical + electrical door closing arm (forgot the name. that thing which closes doors from the top)

  • I hook up the raspberry zero to an ethernet module, a cable from it to a dedicated ethernet router, with no wifi capability, stick that inside a wall and leave only one point of access, through ethernet, on a port behind a panel.

  • I log everything through that ethernet router, onto a dedicated raspberry, a tiny bit more accessible (i.e. behind a screwn-on wall plate. only meant for emergency access).

  • that dedicated logger raspberry uses a sim card dongle to send SMS messages, pre encrypted, to an aws endpoint, which can pre-analyize, notify myself if anything weird might be happening (inclusive of no logs showing up), then cold-store it. (SMS are free here and is a good compromise to enabling some “network communication” without actually being on a network)

  • SMS dongle set up to disregard any and every message coming back.

  • when embedding things onto your walls, use internal walls! never a wall shared with your neighbours.

  • I am considering if I should brick the door handle. this way no one can pick it.

  • I am still considering which mechanism to set in place as an emergency release. currently considering bricking the handle and setting up a ferrous base behind the pin, then a very strong magnet hidden behind the skirting board… but that just seems like too much work :sweat_smile:

  • if you want remote control, I recommend using the SMS module for that (then locally instead of on a logger, and sanitise, instead of disregarding, any SMS input)

  • considering adding an electronic, online, magic eye.

  • adding a camera hidden on a mirror at the end of the main corridor, facing the entry door.

  • I am still messing around to decide if I’m going forward with an USB based ACR122u/PASORI, or a GPIO mounted Wiegand reader. Wiegands reach a better range, but so far they are proving a bit fiddly to read, given GPIOs not being as precise/fast as Wiegand, thus causing some data to be lost here and there… Still hoping to find better range on another reader…

  • I’ll soon rewrite the tag code and share it (once I strip the proprietary bits off of it). The core logic behind it is… read an UID → check against a file which states either: A) open and notify me. B) challenge DF2. Option A is just a backup functionality, doesn’t need to be in place, but allows me to register any HF chip as a “guest” temporarily. Thought of that in case I have guests with their own implants, so I don’t need to hand out some nfc wristbands neither write an application to their chips.

Access is granted based on a file I can edit using ssh through the only ethernet port mentioned, and sshing gets logged and notified to me.

Think those are all my core points. Hope it helps!
Else, just ask away whatever specific you have in mind!

2 Likes

All this talk of security, and then Wiegand?

Also, consider that the wallpaper will get dirty with time if the read range is not stellar and you have to rub your hand against it (think light switches in apartment buildings), leaving a convenient mark.

The hacks on wiegand depends a lot on how it’s integrated.
Applying it over GPIO and sanitizing it + not allowing plain UID access… would mitigate these risks.

Then if I can get a consistent read range boost (on my tests I managed to gain about 5cm), it would mitigate other issues, such as the wallpaper.

Plus on my case it’s a really dark wallpaper full of leafy drawings, so it wouldn’t get as smudged as a white wallpaper.

Does Wiegand do more than just UID? If so, that’s the first time I’ve heard that! Would explain some things…

Wiegand reader systems… No
Wiegand readers… potentially.

You got to modify it enough… and so far, as I mentioned, it leaves that unreliable, at best. :sweat_smile:

I haven’t got it to even read consistently through GPIO so far, so I’ll probably drop that approach anyway.

But I did manage to get it sending modulated pulses. Just way more unreliable, because of GPIO incompatibilities. But theoretically that’s what one would need to be able to use a Wiegand to do a bit more than plain reads.

1 Like

Ahhh ok, so not simply :cry: - I’ve seen how impressive even 2008 RFID systems are (credential caching at the reader level, multiple networked systems per building, master cards, actually using a sector on the card instead of just UID) despite using MFC (it was secure at the time I think?). It makes me sad how inaccessible to individuals that sort of thing is except for maybe the Ubiquiti Access control system.

Totally agree with you there.

Even the things I can do on a Wiegand I can only achieve because far smarter people than me have laid out most of the groundwork for me…

Potential with those readers is immense!
If you could just update them to modern security standards, they would be so much better than anything else on retail! :star_struck:

Yet Wiegand itself took a massive credibility hit when they got exploited… which makes it very comprehensible why they are not investing on a widespread market… :woman_shrugging:

That’s true, but it wouldn’t solve the fact that the Wiegand protocol is inherently insecure.
Also, if you are going to put that much work into it, then you might as well design something much more secure using the DF2 (you mentioned you had some knowledge of it).

Which is probably a no… :sweat_smile:

I mean… that is directly dependant on external factors at this moment.

If I have more time to spend in a very specific work project…

& My solicitors continue to astonish me with their boundless incompetence (i.e. my house move gets postponed again)

& I manage to get some consistency in the reads via GPIO (which looks rather unlikely at the moment)

then I’ll keep adding work into it…

Otherwise I will go back into the USB reader approach + straightforward DF implementation.

I want to write something shareable (i.e. non proprietary neither under NDA) on DF, so I’ll end up writing that code either way…

It’s more about what will happen first. :sweat_smile:

Those are very good pointers! I can tell you’ve put a lot of thought into system failure and security. I have been working on a pcb and code redesign of Paul Walsh’s Simple Sexy module. My redesign is prioritizing IoT and I’m trying to make it a one for all device. I’ll definitely be thinking about redundancy as I continue my coding :slightly_smiling_face:.

I’ve had some of the same thoughts you’ve outlined. With regard to the power failure situation do you think arduino on battery can use as little power as a pi zero while in standby? I wonder how many times an arduino on battery can trip relays before current becomes too weak. I’ll take a look at how access control modules on the market handle power consumption when there is a power failure.