When people hear “file protection”, the first thing they usually think about is encryption.
But encryption isn't the only way to protect a file.
While building ATLOCK v4, I ended up going deeper into a different part of Windows security:
NTFS Access Control Lists (ACLs).
And the more I worked with them, the more interesting the distinction became.
🔐 Two Different Security Problems
Consider these two questions:
Who is allowed to access this file?
and:
What happens if someone obtains the underlying data?
They're different problems.
ATLOCK approaches them differently.
ATLOCK
│
┌────────────┴────────────┐
│ │
FILE GUARD PASSWORD VAULT
│ │
NTFS ACLs Fernet
│ │
Access control Authenticated encryption
That's an important architectural distinction.
- File Guard → NTFS ACLs
Windows already has a sophisticated authorization model.
NTFS permissions can define access for users and groups through an ACL containing access-control entries.
Conceptually:
┌──────────────────────┐
│ PROCESS │
└──────────┬───────────┘
│
▼
┌──────────────────────┐
│ Windows Access Token │
└──────────┬───────────┘
│
▼
┌──────────────────────┐
│ NTFS ACL / ACEs │
└──────────┬───────────┘
│
┌────┴────┐
▼ ▼
ALLOW DENY
The important part is that the decision isn't purely made by ATLOCK.
Windows participates in the authorization process.
That means ATLOCK can work with an existing operating-system security primitive instead of inventing a completely separate file permission system.
- Why Not Encrypt Every Protected File?
Because encryption and authorization have different jobs.
Imagine a file containing:
Project/
├── design.pdf
├── notes.txt
└── source.zip
If I encrypt everything, I introduce a cryptographic data-protection layer.
If I modify access permissions, I'm changing who Windows permits to interact with those objects.
Those are not equivalent.
A useful mental model is:
DATA
│
┌───────────┴───────────┐
│ │
Confidentiality Authorization
│ │
Encryption ACLs
│ │
"Can it be read?" "Can it be accessed?"
That distinction influenced how I designed ATLOCK.
- Password Vault → Cryptography
The Password Vault is a different problem.
Here, encryption is fundamental.
ATLOCK uses Fernet for the vault.
At a high level:
Master Password
│
▼
PBKDF2-HMAC-SHA256
│
▼
Derived Key
│
▼
Fernet
│
▼
Encrypted Vault Data
The Fernet construction provides authenticated encryption using:
AES-128-CBC + HMAC-SHA256
The important point isn't simply saying:
“It's AES.”
A secure design also needs to consider key derivation, authentication, integrity, key handling, and failure behavior.
That's where cryptographic implementations become more than a checkbox.
- Intruder Ops → Event Handling
Then there's Intruder Ops.
The interesting engineering problem here isn't simply:
failed attempt → camera
The real workflow is closer to:
Access Event
│
▼
Authentication / Failure Logic
│
▼
Configured Trigger
│
├───────────────┐
▼ ▼
Alert Evidence Capture
│
▼
Local Storage
And hardware makes this considerably more annoying.
A webcam might be:
unavailable
disconnected
already occupied
slow to initialize
returning an error
behaving differently across systems
A security event shouldn't freeze the application's UI while hardware initialization happens.
That forced me to think about the capture process as an asynchronous workflow rather than simply calling a camera operation and waiting.
- The Real Security Problem Isn't the Feature
This is probably the biggest thing I've learned while building ATLOCK.
Adding:
🔒 File Protection
doesn't automatically make software secure.
Adding:
🔐 Encryption
doesn't automatically make software secure.
Adding:
📸 Intruder Detection
doesn't automatically make software secure.
The interesting questions come afterward.
What happens when things fail?
For example:
ACL modification fails
↓
Did the application detect it?
↓
Was the previous state preserved?
↓
Was the user informed?
↓
Can the operation be safely retried?
Or:
Camera unavailable
↓
Does Intruder Ops crash?
↓
Does the UI freeze?
↓
Is the event still recorded?
↓
Does the application recover?
Security engineering is often less about the happy path and more about the paths nobody wants to test.
🧠 Threat Modeling Changed How I Think About ATLOCK
The more I build, the less interested I am in asking:
“How many security features does ATLOCK have?”
I'd rather ask:
“What threat is this feature actually addressing?”
For example:
Component Primary purpose
NTFS ACLs Authorization
Fernet Confidentiality + integrity/authentication
PBKDF2 Password-based key derivation
Intruder Ops Local response to configured access failures
Lockdown Restricting interaction with the application/system workflow
This makes feature design much more intentional.
⚠️ And There Are Still Questions
ATLOCK is an independent project, not a replacement for Windows' entire security architecture or enterprise endpoint protection.
There are still things I want to investigate more deeply:
ACL inheritance edge cases
Recovery from failed permission changes
Privilege boundaries
Local evidence protection
Process termination and crash behavior
Camera/device failure handling
Authentication state management
Threat modeling against different local attackers
That's the part I'm enjoying most.
Not adding another button.
Finding the boundary where the button actually matters.
🔥 Why I'm Writing About This
A lot of software development content focuses on:
“Look what I built.”
I'm increasingly interested in:
“Here's why I built it this way.”
Because architecture decisions have consequences.
Choosing an existing OS security primitive instead of inventing one.
Separating authorization from encryption.
Treating hardware operations as failure-prone.
Thinking about the threat model before adding another security feature.
Those decisions matter far more than how impressive a feature list looks on a landing page.
Final Thought
ATLOCK started as an application.
For me, it's becoming something more useful:
a practical laboratory for learning how security software actually behaves in the real world.
Every bug teaches something.
Every failed implementation exposes an assumption.
Every user question reveals a blind spot.
And every technical criticism gives me another angle I hadn't considered.
That's the part of building software I don't want to lose.
Don't just build features.
Understand the system those features are entering.
🔒 ATLOCK v4 — Akhouri Systems
GitHub:
https://github.com/Akhouri-Anmol-Kumar/ATLOCK
ATLOCK
"We Build What Others Forgot To Fix"
