Frequently Asked Questions (FAQ)
It is the only keyless, certificate-free, logically-sound, broad-based cross-platform, and cross-device cybersecurity technology in the world.
Traditional security measures focus on:
- Container (also referred to as “end-point”) security for the storage of the digital asset (the digital asset which, when being transported, is the source asset).
- Operating system and browser-protection security at the destination container, memory address, or file systems during transportation.
A better approach, rather than the traditional, is to use enable the digital asset to provide security for itself , typically invoked at runtime when the digital asset is executed or viewed, and which is ignored by a container’s security or by the operating system and browser security provided during transport.
We have become accustomed to seeing a digital asset expressed as a computer file of some kind, but some digital assets spend their entire lifespan in flash or random access memory or as a tabled collection of its component parts in a database. The important things about digital assets are that in their native states they:
- Are recognizable by name or address (location on a storage device or in memory) to a computer program, script or macro, or to a user, including recognition by an unintended computer program, script, macro, or user;
- Can be stored with or without authorization to locations both known and unknown to the digital asset owner as originals or copies;
- Can be moved with or without authorization;
- Are subject to having the originals or copies altered with or without authorization;
- Are intended for use only with, but can be improperly used without, authorization.
AMULETs ™ can certainly handle DRM – they were originally developed as a solution for DRM issues – but they can solve a number of other problems DRMs weren’t meant to handle. DRM has no means to deal with an ad hoc randomly created piece of intellectual property such as an e-mail because of the onerous registration and identification elements associated with centralized control of formal copyrights. AMULETs ™, however, have self-contained and self-generating unique identification mechanisms which require no centralized registration.
AMULETs ™ are a complete end-to-end system managing all data states, a system comprising both process and state data, and do use encryption as one of many techniques they employ. However, decryption is to what we call a first-level Code Cocoon ™ that is not visible to the external world, rather than to conventional memory or to a disk. AMULETs ™ solve the visible decrypted data issue, among other problems.
Because it is expressed as simple plain text, it can travel anywhere on any device or operating system. Because it is free-standing, any number of digital assets, as well as any kind of digital assets, can associate with it for protection. Because it is self-validating – operations on one portion of the AMULET ™ must exactly match the results of a different set of operations on a different portion of the AMULET ™, else the AMULET ™ is known to have been altered or corrupted – the AMULET ™ cannot be compromised in any way.
For example, an AMULET ™ can test that each and every use occurs on the correct machine at the right I/P address at the appropriate time of day in the assigned GPS geographical area. Contrast this to the use of an ‘unlock’ key, where anyone having possession of the key effectively has possession of your application, regardless who or where he or she might be. Finally, AMULETs ™ are dynamic – if the user is online (and you can set a switch that says they must be), you can change the conditions under which the AMULET ™ will allow access, whereas once you issue an ‘unlock’ key, you are stuck with the situation, whatever it may be
- GPS location
- Multiple specifications of time
- Hardware attached to the host device
- Contents of the file system (or lack thereof)
- Calling process and child thread
- Host system BIOS
- Information in an online resource (website, file, or data store)
- Internet and MAC addresses, including available ports
- Windows registry contents
- Input activity prior to use
- Information in a row and column of a database
…and a host of other environmental conditions, both analog and digital, both local and remote.
No, in fact, you do not have to set any criteria values at all – just the mere existence of an AMULET™ and the calling of it on behalf of a digital asset provides significant protection in and of itself. The AMULET™ editor will allow you to save a completely empty AMULET™ for this reason. As to the rest of the criteria, you may set as many or as few criteria values as you wish. Few of the criteria are actually required to have values set, and those that are have appropriate default values set for them in the event you do now assign a custom value.
By setting aside intellectual property or proprietary elements into small protected indecipherable modules, the fact that the still-exposed script can be copied is now made harmless, because that script will not run without satisfying AMULET ™ criteria protecting those critical modules.
Consider a process which takes two inputs and is a trade secret (an informal form of intellectual property not easily protected, and once revealed, is available to everyone without reimbursement to the owner). When the process is successfully executed, it produces an output, otherwise it does not. A developer wants to protect the output as a digital asset for use in software.
Since the mere existence of the digital asset validates correct inputs were entered into the trade secret process, and the inputs compared to the output have a relationship that can be examined to reveal the process, a hacker with access to the digital access output can simply iteratively submit inputs until a digital asset is produced.
Code Cocoons ™ come in two different flavors, and have many, many applications and advantages. One of their disadvantages is the the mounting, dismounting, and maintenance of a hidden RAM drive or virtual machine is costly in terms of CPU cycles, and if not handled properly, can impact the performance of the host device. You wouldn’t want to deploy Code Cocoons ™ capriciously.
However, the trade secret example above is perfectly suited to a Code Cocoon ™, which allows the use of a digital asset in secret without revealing either its existence or non-existence (the caller is never told why the AMULET ™ access was denied, or that the AMULET ™ used a digital asset when it succeeded – contents of an AMULET ™ are never made known except to an authorized author or developer through the editor).
And in case you were wondering, the trade secret problem described about is not something conjured up to fit the question. We see the mistake in security all of the time – even supposed professionals who should know better will tell you in their software written for a logon process (a trade secret if there ever was one) which part failed – the logon name, the password, or the validation question? An incredibly naive thing for a developer to do, because now the hacker needs only to iterate on each one of the three parts of the problem in turn until he finds an answer that works for that part, then move on to iterating for the next part, and so on.
I know you provide an unmanaged C++ Software Development Kit (SDK) that will allow a developer to access AMULET-protected unmanaged C++ modules directly, but I do not know how to code unmanaged C++, or how to access unmanaged C++ modules from my script. How can I use AMULETs™ to protect my plain-text scripts from being copied?
In order to dynamically change an AMULET ™, the target AMULET ™ must recognize your authority to make changes. You must have an identical copy of the AMULET ™ as it exists on the target host before beginning edits, or you must have additional override authority rights. Once these conditions are met, the target AMULET ™(s) can be modified following the instructions for the AMULET ™ editor.
The installation packages we provide in the packaging utilities for new software distribution are highly intelligent and adaptive, particularly when installed onto a system that is online or can be made Internet-accessible. The installer will determine the needed components and versions of the host environment, adding any of our components not already present and updating any that require it.
DSS is the data security substandard for PCI, whereas HIPAA is a performance and policy, not data. Standard data security for HIPAA is provided by independent standards like DICOM and independent rules (not a standard) provided by DHS: http://www.hhs.gov/hipaa/for-professionals/security/index.html.
How can AMULETs™ protect from an internal threat, say an employee who has authorized access, releasing the data/digital asset? For instance, say an Amulet-protected file (document, email, source code, etc.) is authorized to be open in a specific time and place, what prevents the authorized employee from viewing that data, photographing that data and using software to transfer data from the image? What safeguards do AMULETs™ provide in that scenario?
In addition, through the use of stegonography at the time the asset is rendered for viewing, can help mitigate, or at the very least enable tracking down the source of such a breach.
Last updated: November 2016