AMULET™ Framework Services 2017-05-22T20:35:02+00:00

AMULET™ Framework Services

The configuration file in which the AMULET lives has a parent-child relationship with the AMULET . The digital asset AMULET (“item AMULET “) in the configuration file contains an enciphered, codified shorthand describing fully all of the criteria that the AMULET manager must validate before any AMULET -protected digital asset lease requests can be honored. Below is a list of some of the criteria that can be tested – what we refer to as “AMULET framework services”.

AMULET Framework Services Descriptions of examples
1. Other files available (or not available) on the device’s local file system, including tests for path, name (including wildcards), timestamp, file size,  and SHA-2 checksum; Example: “super secret encrypted file must exist in the specified location”

Example: “hidden file’s checksum must match ###”

2. Other processes in (or not in) the host device’s memory; Example: “zeitgeist-daemon process must be running”

Example: “special-applet must not exist as a running process”

3. The module from which access to a protected element is being requested (or from which access must not be requested), including tests for path, name (including wildcards), timestamp, file size,  and SHA-2 checksum; Example: “access request must be from module abc”

Example: “requesting module must be xyz with timestamp of ##/#/##”

4. The process or child thread from which access to a protected element is being requested (or from which access must not be requested), including tests for the launching executable file’s path, name (including wildcards), timestamp, file size,  and SHA-2 checksum; Example: “requested access must be from ABC.dll”

Example: “requested access must NOT be from XYZ.exe”

5. Setting up a protected environment (“code cocoon ”) for the script or code to run in or from, separate and apart from the host device’s physical file system or the running process making the access request; Example: “process run in the protected environment (Code Cocoon ) must be successful”
6. How many instances of the protected element are already running in memory, divided into those called from specific processes and child threads and those called from specific modules?; Example: “allow if protected element is running < 3 times in memory”

Example: “allow if protected element is running only once in memory, and was called from module example4500.exe”

7. Passing access requests through to custom access handlers written by the software developer and plugged into the Certitude system; Example: “requires success from myExternalProcess.exe”
8. Vendor pass-through – if the supplier of an AMULET has supplied a loose restriction on a criteria, and has allowed a re-seller to further restrict that criteria via an authorization logon and assigned permissions, the re-seller can modify the permitted criteria within restrictions, before passing the modified AMULET to his customer. Example: “only allow access if user is administrator level”

Example: “The supplier of an AMULET has restricted usage of the AMULET to IPv4 domain addresses masked by the octet 123.xxx.xxx.xxx. He has allowed a reseller to tighten the range of permitted IPv4 addresses, and the re-seller chooses to restrict the range further to addresses masked by the octet 123.221.xxx.xxx”

9. GPS location testing, for GPS-equipped devices, via simple or combined, inclusive or exclusive GPS polygons, down to specific cubicles in a building; Example: “only allow access if within the defined GPS fencing locations”

Example: “deny access if within the defined GPS polygon”

10. BIOS settings in (or not in) the host device; Example: “device must be 64-bit”

Example: “device must not be using a build earlier than 02.xx.xx.xx”

11. Installed hardware on (or not on) the host device; Example: “Must not have a USB port”

Example: “Must have dongle attached”

12. Internet address(es) assigned (or not assigned) to the host device; Example: “allow access only if IP address matches pattern 123.45.*.*”

Example: “deny access if IP address of machine is “256.*.*.*”

13. MAC address(es) assigned (or not assigned) to hardware on the host device; Example: “allow access if MAC address matches 00:1D:92:A4:xx:xx”

Example: “allow access if MAC address does not match 00:1D:92:A4:56:20”

14. Windows registry contents for devices hosting a Windows operating system; Example: “HKEY_CLASSES_ROOT .bin must have value of {098f2470-abe0-21ds-b684-07302b34des}”
15. Remote controls based on contents of specific files and/or results of program executions on devices accessible by Internet, Ethernet backbone, text (SMS), Wi-Fi, and/or 3G/4G connections; Example: “https://abcde.com/xysil.php must return value greater than 10”
16. For camera-equipped devices, images of the user and the environment during invocation; Example: “at time of request, activate camera for 1 second and ….”
17. For audio-equipped devices, recordings of the auditory environment during invocation; Example: “at time of request, activate sound recording and forward to …”
18. Time – controlling invocation within time ranges of any length, patterns of repetition, or number of repetitions and/or by the host device’s time zone(s);

(see the Time Criteria page for more information)

Example: “allow access to asset between 3PM and 5PM each weekday”

Example: “deny access on Saturdays”

19. Logged-on user or user group memberships; Example: “allow access if user is member of the Premium group”

Example: “deny access if member belongs to black_ball group”

20. Known Virtual Machines – Multiple checks tailored to known virtual machine and virtual containers (Spoon Studio, Docker, etc.) see if the digital asset is being run in a virtual environment, and whether running on a VM is permitted by AMULET settings. Secondarily, if running on a VM, the AMULET can be checked to see if the VM has Internet connectivity and whether running without such connectivity is permitted (mounting a registered application on a VM and shutting off Internet connectivity to void any phone-home capability is a technique used to distribute free applications without paying royalty fees and the additional instances of the applications – entire development environments for Windows and mobile application development using high-end tools are often distributed in this manner); and Example: “deny access if running in a Docker environment”

Example: “only allow if running in Spoon Studio VM”

21. User keyboard and mouse activity (or lack thereof). Example: “Deny access if there was has not been user activity on the host device within the prior 15 minutes”
22. Operating system (i.e., Windows, Linux, iOS, OSX, Android, etc.) and version. Example: “deny if O/S is Android and version is 4.2 or earlier”