When I started building ATLOCK, I initially thought about file protection as an encryption problem.

Then I realized something:

Encryption and access control solve different problems.

So for ATLOCK's File Guard, I went in a different direction.

Instead of encrypting every protected file, ATLOCK uses Windows NTFS Access Control Lists (ACLs) to control which identities are allowed to access protected files and directories.

That sounds simple.

The implementation isn't.

🔒 Why NTFS ACLs?

Windows already has a permission system capable of controlling access to files and directories.

NTFS ACLs allow permissions to be defined around things such as:

Users
Groups
Read access
Write access
Modify access
Full control
Inheritance
Explicit deny/allow rules

So rather than inventing a completely separate permission layer, ATLOCK can work with a mechanism Windows already understands.

The basic idea becomes:

User
↓
Windows Security Token
↓
NTFS Access Check
↓
ACL Evaluation
↓
Allow / Deny
↓
File System

That gives ATLOCK an interesting property:

The operating system itself participates in the access-control decision.

🧠 Encryption vs. Access Control

This distinction became one of the most important design decisions in ATLOCK.

Encryption asks:

“Can someone read this data without the key?”

Access control asks:

“Is this identity allowed to access this object?”

Those aren't interchangeable.

For example, a protected file can remain completely normal on disk while its NTFS permissions determine who can interact with it.

That's useful for a tool like ATLOCK because I wanted the File Guard feature to integrate with the Windows filesystem rather than creating a completely separate encrypted container format.

🔐 The Password Vault is Different

The Password Vault has a different security requirement.

Here, encryption is the point.

ATLOCK uses Fernet, which provides authenticated encryption based on:

AES-128-CBC + HMAC-SHA256

The encryption key isn't simply derived from a user's password and used directly.

ATLOCK uses:

PBKDF2-HMAC-SHA256

for password-based key derivation.

That gives the architecture two different protection mechanisms:

             ATLOCK
                │
      ┌─────────┴─────────┐
      │                   │
 File Guard          Password Vault
      │                   │
 NTFS ACLs             Fernet
      │                   │
Access control       Encryption +
                     authentication

I actually prefer this separation.

The security mechanism should match the problem.

📸 Then There's Intruder Ops

ATLOCK also has an Intruder Ops module.

The concept is straightforward:

Access attempt
↓
Authentication failure
↓
Configured threshold/event
↓
Intruder Ops
↓
Evidence capture / alert
↓
Local storage

The interesting engineering problem wasn't just capturing an image.

It was making the capture process not interfere with the main application workflow.

Camera initialization can be slow.

A webcam can already be occupied by another application.

Hardware availability can change.

And a security event shouldn't freeze the application's UI while the camera subsystem initializes.

That forced me to think about the feature as an asynchronous workflow rather than:

capture()
wait()
continue()
⚠️ The Part I'm Still Thinking About

Building security software taught me something uncomfortable:

Adding a security feature doesn't automatically make software secure.

Every additional privileged operation creates another place where something can go wrong.

That's why I'm increasingly interested in threat modeling rather than simply counting features.

For ATLOCK, questions like these matter:

What happens if another process already owns the camera?
What happens if ACL modification fails halfway through?
What happens if the application crashes during a protection change?
What happens if permissions are inherited unexpectedly?
What happens if a user loses access to a protected directory?
What happens if the local evidence storage itself is modified?
What security boundary does ATLOCK actually provide?

Those questions are much more interesting to me than:

“How many features does the app have?”

🔒 That's What ATLOCK Is Becoming

Originally, ATLOCK was simply a collection of security utilities.

Now I'm treating it more like a security engineering experiment.

Use Windows' existing security primitives where possible.

Use cryptography where confidentiality actually requires it.

Keep security events local.

And constantly question the threat model.

If you're a Windows developer or security engineer, I'd genuinely like your criticism:

Where would you attack this architecture first?

ATLOCK v4:
https://github.com/Akhouri-Anmol-Kumar/ATLOCK

ATLOCK

"We Build What Others Forgot To Fix"