Oleksandr Bezdieniezhnykh
2.1 KiB
Security Tests
NFT-SEC-01: Unauthenticated resource access
Summary: Verify resource download fails when no credentials have been set. Traces to: AC-4 (negative), AC-14 Category: Authentication enforcement
Preconditions: Loader service is running; no prior login.
Steps:
| Step | Consumer Action | Expected System Response |
|---|---|---|
| 1 | POST /load/testfile without prior login | HTTP 500 (ApiClient has no credentials/token) |
Expected outcome: Resource access denied when not authenticated
NFT-SEC-02: Encryption round-trip integrity
Summary: Verify that encrypt→decrypt with the same key returns the original data (validates AES-256-CBC implementation). Traces to: AC-11 Category: Data encryption
Preconditions: Upload a known resource, then download it back.
Steps:
| Step | Consumer Action | Expected System Response |
|---|---|---|
| 1 | POST /login with valid credentials | HTTP 200 |
| 2 | POST /upload/roundtrip multipart (file=known_bytes) | HTTP 200 |
| 3 | POST /load/roundtrip with body {"filename": "roundtrip", "folder": "models"} |
HTTP 200, body matches original known_bytes |
Expected outcome: Downloaded content is byte-identical to uploaded content
NFT-SEC-03: Hardware-bound key produces different keys for different hardware strings
Summary: Verify that different hardware fingerprints produce different encryption keys (tested indirectly through behavior: a resource encrypted on one machine cannot be decrypted by another). Traces to: AC-12 Category: Hardware binding
Note: This is a behavioral test — the consumer cannot directly call get_hw_hash() (Cython cdef). Instead, verify that a resource downloaded from the API cannot be decrypted with a different hardware context. This may require mocking the Resource API to return content encrypted with a known hardware-bound key.
Preconditions: Mock API configured with hardware-specific encrypted response.
Expected outcome: Decryption succeeds with matching hardware context; fails with mismatched context.