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 digital 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.
Digital assets are usually thought of as computer files, but for our purposes (and what the AMULET ™ system can work to protect), a digital asset can be just about anything digital (for example, software application, image, music, movie, document, or even a programming script).
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.
No it’s much bigger than DRM, though DRM is a small subset of the various problems AMULETs ™ solve. For example, let’s assume you purchased 100 licenses of Microsoft Word for use by your employees. You didn’t invent Microsoft Word, so you don’t own the copyright or any other intellectual property associated with it. You simply want to ensure the “right” 100 people are using those Word licenses within your organization at any one time so you are getting the most productivity out of it. DRM won’t help you much with this issue, whereas the AMULET ™ system, with its dynamic and rich set of available criteria, can handle this and much much more.
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.
Data encryption is merely the reversible obfuscation of data, usually done to hide data content in the stored state. However, encrypted data is not usable in the encrypted state, and must be decrypted before use, and this is its Achille’s heel. Hackers try to intercept either the data immediately after decryption, or the key used to decrypt the data. That’s what hacking is.
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.
“AMULET ™” stands for Autovalidating Metadata as a Unique Lexical Enciphered Tag, and is a plain-text enciphered expression of a highly-efficient self-contained database which has in it various owner-, developer- or author-defined criteria for the environmental conditions that must be present – who, what, when, where, and how – before access to an associated digital asset can be granted.
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.
AMULETs ™ can protect any portion of a digital asset down to a single line of code, byte of date, pixel in an image, or frame of a video. An AMULET ™ could also protect a large group of related digital assets, such as all the modules of an application, or contents of a database, or entire files system. An AMULET ™ is often used one-to-one with a single whole digital asset, but it need not be.
No, not necessarily. You could have several different assets reference the same AMULET ™ for protection. The AMULET ™ includes the criteria that must be satisfied for accessing the digital asset, so if you have a set of criteria that could be used across many different digital assets, then you could use the same AMULET ™ for those digital assets. Conversely, you could also use many different AMULETs ™ to protect a single digital asset.
Yes. Even dissimilar digital assets can share an AMULET ™, and the digital assets need not have the same owner (though an AMULET ™ can defend itself against unwanted use).
By registering with an AMULET ™, you can set dozens of conditions the user must meet each and every time he/she starts up the software (as opposed to an ‘unlock’ key which can test only for the existence of the key and which, once given to the end user, is good for all subsequent uses to the end of all time).
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
AMULETs ™ are the only form of digital asset security which can consider (unique to the protected digital asset at the very point and time of requested access) such a diverse range of dynamic runtime criteria, including:
- 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.
The ecosystem is provided as a lightweight framework on each AMULET ™-capable device, one instance of which serves all AMULET ™ access request. The only other software required is an editor for stipulating the security criteria of an AMULET ™ (which can then be used one-to-many to protect digital assets, or many-to-one if compounding of security criteria among several AMULETs ™ is desired). The peer-level metadata used to define an AMULET ™ is both cross-platform and cross-device, meaning that the metadata is free to float in space until needed. The framework provides all environmental analysis required at real-time point of digital access. The framework knows how to interpret all AMULET ™ metadata.
For complex AMULET ™ criteria, system load and therefore per-instance access time is very-high-stress device circumstances. Properly handling AMULET ™ access rejections is a cost, as is converting legacy digital assets to use AMULETs ™ (made less so by automated tools we provide).
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.
This type of digital asset is protected similarly to all the other methods and options discussed, but provides the author the ability to include a low-resolution, low-frame-rate, low-sample-rate version of the video to non-authorized viewers. In addition, a different AMULET ™ can be used to protect certain portions of the video seen by an authorized viewer, so that even the high-resolution part of the video can have sections within it that are protected further (as an example, premium content).
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.
AMULETs ™ are complementary to, not in competition with, those standards and extend security from the system to the individual digital asset. Both standards can be defined as AMULET ™ criteria for AMULET ™-only protection.
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?
AMULETs ™ are unlike any other existing security technology in that they do the assessment of the environment at the very moment of each individual access of a digital asset. Therfore AMULETs ™ are sensitive to changing conditions. Authors, not users, control access, so the first scenario (an employee “”releasing”” a digital asset) is not possible. AMULETs ™ can monitor and mitigate anything being done on the host device, but cannot control a separate device outside its purview, such as a camera. However, content displays through the proprietary AMULET ™ viewers can make photography difficult by manipulating the display contents between buffers.
In addition, through the use of steganography at the time the digital asset is rendered for viewing, can help mitigate, or at the very least enable tracking down the source of such a breach.
We would never constrain AMULETs ™ by forcing the user to be online to gain access to a protected digital asset. We would never expose a protected digital asset to the additional attack surface of a round-trip of sensitive data of any kind to and from an Internet server – just the act of making the connection to a server tells a hacker something. All that is needed for an AMULET ™ is peer-level metadata already resident on the device. Security-as-a-Service is self-defeating in the same way container-related digital asset protection is – it exposes a broad attack service where the rewards of breaching that service are huge because of the number of accessible digital assets naked behind that wall. When nation-states are engaged in the hacking, the economies of scale also apply to their hacking task. To say that literally putting all your eggs into one basket (which is the economic benefit to SaaS) is an incredibly bad approach.
Last updated: November 2016