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:

  1. 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).
  2. 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:

  1. 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;
  2. Can be stored with or without authorization to locations both known and unknown to the digital asset owner as originals or copies;
  3. Can be moved with or without authorization;
  4. Are subject to having the originals or copies altered with or without authorization;
  5. 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:

  1. GPS location
  2. Multiple specifications of time
  3. Hardware attached to the host device
  4. Contents of the file system (or lack thereof)
  5. Calling process and child thread
  6. Host system BIOS
  7. Information in an online resource (website, file, or data store)
  8. Internet and MAC addresses, including available ports
  9. Windows registry contents
  10. Input activity prior to use
  11. 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.

The system is fail-safe, meaning that the design will deny access to a protected digital asset in the event of attempted breach. This means that the worst that could happen is that an otherwise-legitimate access request could be denied for one instance only of an access request. The system requires threading capability from the O/S, and support for shared-memory data segments, which means it will not be supported on older legacy devices. Some features (VM Code Cocoons , for example) require sufficient resources be available on a device, and if not present, will not be active.

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).

No. AMULETs can protect legacy code already written with very little modification. AMULETs can also protect non-software items like files, audio, video, images, documents, multimedia, e-mail, items in a database, even abstractions like network connections or a virtual object.
Yes. Using the AMULET set-aside-and-wrap-critical-components approach is an absolute boon to programming script authors, whose work could never before be published because it is rendered in plain text, easily copied in any text editor.

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.

AMULETs were originally invented out of concern for the intellectual property of an author or developer, as bound into, represented by, created by, or implemented by a digital asset, and now AMULETs protect both the intellectual property and the digital asset associated with that I/P. Intellectual property can represented by both nouns (a physical thing) and verbs (i.e, process or calculation) – intellectual property (IP) can even be represented by the mere existence of something that wasn’t there before (i.e., the result of a process or calculation). The fact that IP and digital assets are not the same things, but have an association, actually has great importance in how a digital asset is protected with AMULETs , especially when Code Cocoons are taken into account.

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).

No. The full-version portion of the multimedia file is enciphered and contains links to an AMULET identifier. The full-version portion of the multimedia can only be played with the permission of the AMULET , and even then only if the original file remains unchanged.
Generally, no, though of course we cannot stop some foot-shooting behaviours that could conceivably slow things down (to prevent this, engage one of our authorized AMULET validation services to vet the criteria you have selected). AMULET criteria are actually not processed at the time access is requested – they are processed ahead of time by a separate process thread that independently re-validates each AMULET every few seconds. When the AMULET access request is made, the system merely needs to pick up the enciphered small piece of code that whether the last AMULET result of the thread’s AMULET™ analysis was successful or not.
Yes, you can nest AMULET access requests inside one another to easily combine criteria settings from multiple AMULETs . Since all AMULET access requests are pre-validated, no significant impact occurs when you nest AMULET requests (within reason, of course). There is no limit within the AMULET system as to how many levels can be nested, though the host device or operating system may have preset or resource limitations that will affect the number of nesting levels.
Yes. However, your access will be controlled by any changes the vendor makes to their AMULET (including removal of the AMULET™ config file container in which it lives), and the vendor can use process thread, process module, and other criteria to prevent someone else using their AMULET . We fully expect device vendors, operating systems, and security services, to offer their own AMULETs with published criteria for general public use.
We (and our third-party partners) will provide a wealth of helper utilities, tutorials, and pre-written accessor scripts to automatically convert scripts in common scripting languages to use AMULET protection. We, as well as third party developers, will also provide consulting services to analyze and identity where to make best use of AMULET protection, and can even do all of the work of converting scripts for you.
Yes, but only the low-resolution front portion of the files. The legacy application must be made AMULET -aware through one of the AMULET plug-ins, add-ons, extensions, or converters that will be made available from either ourselves, or third party developers, for popular applications in order to view the full-resolution image hidden in the file. Otherwise, you will need use one of our, or one from a third party, AMULET -aware players or viewers to see the image in its full resolution.
You will need to have previously installed an AMULET plug-in, add-on, extension, or converter to a legacy e-mail client, or use one of our, or one from a third party, AMULET -enabled e-mail client. Write and address the e-mail as you normally would, add any attachments, and click the send button. You will be asked to choose a pre-defined security template or specify your own custom security settings for the e-mail (which you can optionally save as a template). Once security has been set, the e-mail will then be sent (behind the scenes, an AMULET will be created or copied as is appropriate for your chosen security settings, the body of your e-mail and any attachments will be enciphered as plain-text, and the AMULET will be attached the enciphered plain text as a new e-mail, with the original subject line intact).
You will need to have previously installed an AMULET plug-in, add-on, extension, or converter to a legacy e-mail client, or use one of our, or one from a third party, AMULET -enabled e-mail client. Click the AMULET -protected e-mail subject line you wish to read. The attached AMULET will be analyzed, and if the security criteria is met, the e-mail and any attachments will be deciphered and rendered in their original form subject to any copy or other restrictions in the AMULET criteria – copy-restricted attachments will be placed on a temporary read-only RAM drive for viewing.
AMULETs can be changed dynamically individually or in groups (broadcast) if the target AMULET (s) were set up to do so and certain other conditions are satisfied. AMULETs whose hosts are online and accessible and for which you know their online addresses and ports can react to your changes immediately; target AMULETs can even “phone home” and report their address and ports whenever those change if set up to do so. Even target AMULETs that are offline or for which you do not know their current address or ports can react to AMULET changes, though in delayed fashion – the AMULET must have been set to periodically touch base with the server from time to time and pick up any changes left for it.

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.

a. Define the criteria of the AMULET (i.e. what do you want the host environmental conditions to be, or not to be, at the moment the access request is made?); b. Run the automated tool to integrate the dependency upon the new AMULET ID into the digital asset(s) to be protected; c. If the AMULET conditions are to be changed if and when the protected digital asset is registered (optional), provide the server and code for doing so. Mass-distribution AMULETs and their protected digital assets can be deployed in a few moments by an organization familiar with the process, more quickly for new digital assets (because the developer most likely has already defined the AMULET™, having programmed his/her code for the expected criteria).

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.

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.

The Citadel, a well-established military university in South Carolina, and designated as a National Center of Academic Excellence in Cyber Defense Education through academic year 2021 by the National Security Agency and the Department of Homeland Security, has had their faculty and staff reviewing, testing, and vetting the AMULET source code for the past eight months. It has not been field tested commercially (we are still in the process of writing a demo for non-technical users).

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