Get Adobe Flash player

Frequently Asked Questions

[Q] If TAIS is secure, why doesn't everyone use it?

[A] In order to use TAIS, the applications must be deployed using a special environment, so TAIS won't fix security problems with popular Operating Systems. However, these systems can be configured with TAIS to become more secure.


[Q] If TAIS is still evolving, how can it be called Absolute Security when there may still be errors or issues?

[A] The TAIS model is not yet perfect and regularly undergoes updates, just like software. In fact, not only is the theory unproven, but it is not expected to be in a state ready for proof until at least 2018.

However, TAIS does provide a checklist and roadmap for building secure information systems. Although it is recognised that it would take a massive effort to implemented TAIS fully (and is therefore mostly unattainable) it still provides a systematic framework for IT personnel to build secure information systems. TAIS is useful because it identifies all the factors that could pose a security risk for information.

Blueicon Technologies treats the construction of TAIS solutions as a moving target and views it in parts;

• The ongoing evolution of the TAIS theory
• The testing and accreditation of various implementations of TAIS


[Q] How do I create a secure application with TAIS?

[A] The BI3 Emulator is software designed to comply with the TAIS theory. As of October 2010, it is not yet possible to create a secure application using the BI3 Emulator, although that situation is fast changing. The BI3 is expected to upgrade its communications to the Advanced Encryption Standard (AES) and implement code verification for agents that execute on it. There are a number of other components that will be added to the BI3 that will take it closer to TAIS compliance.


[Q] Why would I trust an unproven information theory?

[A] TAIS is essentially about a commonsense approach to securing information. It is designed to be easy to understand and implement. Building applications that are TAIS compliant are likely to be more secure than alternatives because TAIS provides a comprehensive framework that identifies all the factors that could affect an information security deployment. Ultimately, it is hoped that TAIS will be proven to be true, but until then we must rely on the intuition of experts in the field that can demonstrate no fundamental violation is taking place.


[Q] Who is eligible to participate in the BI3 Ethical Hacking Challenge 2011?

[A] Although the challenge is targeted at undergraduates, a wide spectrum of participation is encouraged. There is an official intake every semester, but participants may enrol at any point. The advantage of enrolling during an official semester intake is that participants will be able to apply exploits to deployments created by participants of the same intake. This has the advantage that productive conversations can take place on the website forum. For research orientated projects, postgraduates can enrol at any point and utilise the course material however they see fit. These research type projects that are out of sync with the general timeline will forfeit the opportunity to penetrate test deployments from the current enrolment. They will however, have the opportunity of loading any past deployment in the image library. Blueicon Technologies encourages research in whatever form including government, private sector and military, but high school students are not eligible.


[Q] How many Capstone teams have been involved with the technology?

[A] Since 2001, approximately 25 Capstone teams have reviewed various aspects of the grid technology that are related to the Theory of Absolute Information Security. The Ethical Challenge started in 2010 with 4 Capstone teams by taking a limited (external) view to penetrate testing with traditional tools only. 2011 provides a far more complete view of the system and an in depth review of the architecture is undertaken. We expect at least 15 – 25 international teams to enrol throughout 2011.


[Q] What is the purpose of the Ethical Hacking Challenge?

[A] The Theory of Absolute Information Security (TAIS) is an extensive theory for securing information. Although it has taken over 10 years to get it to this point, it still has some way to go. The theory is not yet ready for publication and so by involving academics in a Capstone style framework, the theory is able to evolve into a more mature form.


[Q] Where can I get a copy of the Theory of Absolute Information Security?

[A] The theory is available for download at http://www.blueicon.com/downloads.html


[Q] What is the origin of the Theory of Absolute Information Security?

[A] TAIS evolved from the high level conceptual ideas proposed by Professor Kay Fielden in 2003 in a paper titled "The Interoperable Information Infrastructure (III) Model". These ideas have been explored in the TAIS theory with contributions from a number of individuals and companies, but primarily overseen by Professor Fielden. The theory is currently managed in custodianship by Blueicon Technologies Limited, whose goal is maturation by way of academic collaboration. At this point in time (2011), Blueicon Technologies has taken the lead in co-ordinating the evolution of the theory, primarily because Blueicon is funded by private investors who would like to see the theory have global acceptance. However, as the theory becomes more widely accepted, Blueicon Technology intends to transfer the management of the theory to a suitable academic institution.


[Q] Does anyone win the Challenge?

[A] The Ethical Hacking Challenge is not a competition as such. Instead, it is an opportunity for participants to take up the challenge by building a secure deployment that cannot be hacked. At the same time, they are encouraged to hack other participant’s deployments. Furthermore, participants are encouraged to contribute to the theory itself, either through improvements to the model or coding efficiencies. Saying this, Blueicon are not ruling out a competition style framework for 2012, and it is quite feasible that prizes could be offered for the winners in the future, for major contributions or for potential errors found.


[Q] There are many forms of security today that incorporate user and device access, so how can TAIS be offering anything different?

[A] Today (2011), user and device security is often bundled up in solutions such as Network Access Control (NAC) that will validate a particular device as being a low security risk based on a general algorithm for determining its trustworthiness such as the Operating System, software and patches that have been installed. This is a very crude mechanism because it doesn’t take into account necessarily what additional software or documents with execution capabilities (like Macros) have been run since the original installation, and even if it does, it doesn’t verify that this code is not a potential Trojan. If it does, then this may make the authorisation too sensitive and a person may be denied access after they review a potentially ‘dangerous’ document or have installed a software update. There is also very little that this authentication software can do to fully protect against sophisticated attacks where the machine configuration may have been modified and the machine simply misrepresents its true state.

TAIS is different to this because it identifies the machine and the exact path via a sequence of peerto-peer connections that will link that machine (TAIS is not founded on TCP/IP although it can use it as a transport layer). TAIS does not try to evaluate the integrity of the machine directly, but relies on the person administering the information cluster (called an Infoscope and handled in the TAIS Epsilon Environment) to have verified the integrity of this machine beforehand. This integrity need only be done once (provided the machine hasn’t been physically tampered with) because TAIS prevents software that it runs (inside a sandbox) from compromising the machine. This means that the machine will never become compromised, provided all information is accessed via TAIS. In high security scenarios, the machines used to access information may be preconfigured to operate with high (physical) security, monitoring and within a Faraday Cage to avoid Tempest scanners that are looking for electromagnetic radiation leakage.

TAIS is not concerned with the cost implications of how to achieve this high-end security, so for example, it may be cost prohibitive to enforce a lockdown of employee mobiles and laptops so that they only execute the TAIS emulator. However, some organisations may opt for a hybrid approach by accepting some device risk, by preventing the installation of new software.

Another area where user and device access is different from today’s systems is in the granularity and scope for which the device access controls have been assigned. Generally today, devices are either recognised as safe or unsafe and are then allowed onto the network. In TAIS, the Infoscope specifies the devices that may be used to access the information, but from the perspective of any single device, the user may still access whatever information is available for which their device has access, so it may log onto the network, regardless of its integrity. This allows less sensitive information to be available. A characteristic feature of TAIS is that compromised machines can safely join the network without compromising other machines.

Another major difference that will become apparent in the TAIS Zeta Environment (TZE) is that each user has access to their own files and these files are dynamic references that are shared between users. This is different from today where users have access to common directories and all share the same files.

There are many subtle differences between the systems in use today (particularly DAC Linux/Windows type systems) and the TAIS model – for example users of TAIS are able to forward documents without the fear that the receiver will not disseminate the information accidentally or deliberately, or looked at another way, a user can be forwarded a document by someone who does not have access to that document.


[Q] There is a big trend today in taking systems offline so that people can work with them on planes for example. The theory appears to enable dynamic collaboration, but what if a person is offline, how can they access their work?

[A] TAIS is not an implementation, it is a theory of securing information and measuring it. It involves an abstract architecture that allows computers to connect adjacently in a peer-peer fashion. As a result, it is ideal for the peer-to-peer connectivity between mobile phones or laptops, such as being conducted by TerraNet in Sweden (2011). TIAS anticipates that connectivity will continue to increase in the mobile area to the point where an individual that is beyond both the range of a base station and another mobile phone will be extremely rare. Airlines are starting to provide WIFI access and are most probably going to enable connectivity as we move into the future. However, to answer the question fully, it would be true that without connectivity, the user cannot access information in the same way that they couldn’t access the Internet without connectivity. On the other hand, the TAIS architecture is already distributed, so it is possible that parts of the database could be separated for extended periods of time and still operate effectively, for example in a military submarine, by locking data at a fine granularity instead of entire files.


[Q] How can an implementation of TAIS really protect schools and children unless it is integrated within the OS so deeply that the user can't use the PC to access anything but the Infoscope system?

[A] This is actually a correct assumption and not just for schools either as it applies to anyone using a TAIS implementation. In any TAIS deployment it is critical that access is limited to the TAIS system and the execution substrate (such as Windows) is hidden. TAIS does not try to fix an already broken architecture (Windows), it is merely a recipe for achieving extremely high measurable security. In order for schools to utilise the system, the children cannot have access to PC Operating System directly and must utilise only the TAIS environment (probably via emulated software).

Even in the TAIS Alpha Environment (TAE), it is a major advantage to ultimately remove the execution substrate entirely and run TAIS as a dedicated client, because this removes the risk posed by these supporting substrates.


[Q] How can the system protect anyone from say a Macro Virus that is already present on the device that they are using to connect to the TAIS system? If a user is authenticated then what stops them from saving a macro onto the TAIS system that has been put into their spreadsheet knowingly or unknowingly? If the TAIS system prevents users from connecting without approved Anti Virus and Virus definitions, then you are blocking 90% of potential users. Isn’t this a problem?

[A] This is a great question because it highlights the difference between the TAIS model and the systems in use today. Although the question is loaded in the sense that it has a number of assumptions, let’s break it apart and see how this relates to TAIS.

Firstly, the TAIS system will not protect an end point device from any kind of malware that may already be installed on it. TAIS refers to this as the execution substrate and it is a prerequisite (in the TAIS Alpha Environment) that the substrate is not compromised. The mechanism for this is linked to a computing concept called the Malicious Host Problem which states that any layer providing the computation will be able to both read and modify any layer for which it hosts. In fact, the complete removal of this execution substrate is desirable. No doubt this makes it difficult and inconvenient for existing platforms to support both TAIS and their native functionality simultaneously. TAIS is probably more suited to hardware manufacturers that can lock down the machine in some tamper resistant form (like embedded systems). TAIS is not concerned with how this lock down occurs, it is primarily concerned with securing information. Practically, a potential cost effective solution could be to boot into a secure partition that restricts access to everything other than the TAIS system. The mechanisms used to do this all are accounted for in the final risk function. So, for example, TAIS will happily let you run native applications alongside the TAIS emulator, but the risk profile for that device will be high, but this does not affect the risk of the rest of the information system. The information that will carry this additional risk is limited to special information containers called Infoscopes.

The question also refers to authentication and is framed in the Network Access Control (NAC) paradigm. The NAC approach tries to make a best guess validation of each access device. This is good in the sense that it is practical and generally anyone can access the information most of the time, but is bad in the sense that it doesn’t make any guarantees about a particular device being secured, and hence the security promise is undermined. TAIS is different because all devices are automatically authenticated and the user is able to access all the information for which their device has clearance. So for example, low security information may be stored in an Infoscope that allows all mobiles and laptops with a particular security profile to be accessed. At the extreme end, Infoscopes that store public information will probably be configured so they can be accessed by all devices, but not all those devices will be able to access information in other Infoscopes.

The next part of this question asks what is stopping a user from copying an infected document from their local machine into the TAIS system. Again, this is a violation of the execution substrate prerequisite of the TAIS Alpha Environment. The user cannot drag anything from their native machine into the TAIS environment without violating Factor TAE 1A (Alpha Environment) and the Alpha Environment certainly doesn’t allow for drag and drop from the execution substrate. More to the point, users can only copy and modify documents that they already have access to within the TAIS system. Even within the TAIS system, there are limitations to where documents can be moved. Information is retained in an outer envelope called an Infoscope and it is impossible to drag information from one Infoscope to another. In this way, non-IT leaders can easily control the dissemination of their information, such as the leader of a political party preventing emails being disseminated beyond their caucus.

This question is leading to another question “If the substrate can’t be used, how can we view conventional software like Word (and Word Macros that may contain viruses)?”. TAIS is a clean-slate approach to security and doesn’t present the Windows Operating System. To achieve this kind of backward compatibility, a PC emulator is required that runs on the TAIS implementation. The desired OS and applications need to be loaded on to the PC Emulation.


[Q] How does simply authorising the user prevent ID Theft in TAIS?

[A] The TAIS system will only prevent ID theft for applications that are hosted within the TAIS system itself. TAIS will not protect an individual from having their identity stolen in a hire purchase type scenario that uses non-TAIS systems. TAIS allows the individual to structure their information in various security levels. Sensitive information such as money or the ability to authorise a transaction, can be kept in secure Infoscopes that can deny access from devices that have inadequately authorised an individual. These Infoscopes act like a virtual safe to keep sensitive information safe while still allowing access to less sensitive data. In practice, an Infoscope may allow virtual devices that represent the accumulation of multiple forms of authentication such as password and confirming a code that is received on the user’s private mobile phone. Depending on the level of authorisation, the virtual device will select a device ID that will unlock Infoscopes with more capabilities for the user. Regardless, if the user doesn’t have sufficient authorisation, then they will be limited to the type of transactions they can commit. At worst, this is impractical, but it does prevent the direct theft of the individual’s ID for applications that are hosted by the system.


[Q] How does TAIS compare to the Bell-LaPadula Model and the Biba Integrity Model?

[A] Bell-LaPadula was designed for military and government applications and is primarily concerned with access control to information. The Biba Integrity Model improved on the design to ensure data integrity by preventing lower authorised users from modifying information created by a higher ranked entity.

TAIS is not limited by this hierarchical view. TAIS’ primary advantages are that both information and people do not have to be classed in a ranking order, which is an unnatural fit for information. Quite to the contrary, TAIS specifically does not require information to be grouped in terms of its security profile, but rather information can be grouped in whatever fashion best relates to the natural context to which it belongs. For example, the fluid nature of information causes libraries major categorising issues when books fall into multiple areas. TAIS allows information to not only occur in an unlimited number of contexts by using Set Theory, but it doesn’t impose an artificial dominating “security” category that both Bell-LaPadula and Biba do.

TAIS achieves the security with Infoscopes that seamlessly integrate with whatever classification is determined by the creator of the Infoscope, as opposed to Bell-LaPadula and Biba that require the Administrator to do this.

Finally, human error can cause a problem in the Bell-LaPadula and Biba when information or people are incorrectly classified. Furthermore, this problem is exacerbated over time as the deployment landscape shifts and data is not updated. TAIS suffers from none of these issues because information is not centrally classified into cumbersome security structures, so deployment costs and potential breaches are minimised.

TAIS is a holistic solution, so it specifies the implementation requirements to lock down physical hardware as well as prevent information leakage during consumption, where Bell-LaPadula and Biba are quiet on this issue and leave it to the IT engineer.


[Q] How does TAIS compare to mandatory access control (MAC), discretionary access control (DAC) and role-based access control (RBAC)?

[A] All these models focus on access control to information, leaving the question of device integrity unaccounted for.

The security model used by most mainstream operating systems is based on Discretionary Access Control (DAC), which enforces security by ownership. If a user owns a file, he is allowed to set the read, write, and execute permissions for that file. In this model, users control the data at their discretion. The owner of the system does not have total control over the system; the users do.

However, the biggest concern with the Linux model is the danger presented by the root account. This super-user has the power to control all files and processes. If the root account, or a process that runs with its privileges, is compromised, an attacker can take control of the system and its data.

A more secure approach would limit or even eliminate the need for a root account, and shift the power from the user accounts to the owner of the system. This is MAC's approach.

MAC makes the enforcement of security policies mandatory instead of discretionary, as you might imagine from the name Mandatory Access Control. Security policies can be set by the system owner and implemented by a system or security administrator. Once these policies are in place, users cannot override them, even if they have root privileges. With MAC, file and process protection is independent of owners

- Paul Virijevich, Securing Linux with Mandatory Access Controls, 2005



In this light, DAC allows users to own files and pass this ownership to other people. This is fundamentally dangerous, because once a file has been transferred, it is not straightforward to retrieve it. A major disadvantage with this model is that this kind of information breach is likely to go undetected. A breach like this can occur in many ways. For example:

     1. Person A is trusted and copies file X
     2. Person A copies File X or parts of X to new file Y but saves it with lower security
         privileges in a way that allows non-trusted person B to access it.

This kind of problem often occurs unintentionally because person A uses software that opens the file; they then copy some of it out into another file. In the process, they may not realise that some of that material may be sensitive.

Both the MAC and TAIS system avoids problems that arise with DAC permissions. For example, let’s say that a complex directory structure has a single high security file inside it for which the user can’t copy. Then, a DAC system will abort, leaving a mess for you to figure out. With TAIS, the copy is instantaneous because it is done via a single instruction that references the parent directory itself. The copy will always occur because permissions do not pose an issue at the storage level. It’s just that the user cannot see the single file for which they are not included in its encapsulating Infoscope. With the MAC approach, this is also not a problem because all the files and users are at the same security level (for that operation).

TAIS is closer to MAC in that there are no owners, but in TAIS users hold their own files and sharing is performed purely referentially. In MAC and DAC, sharing occurs at specific directories. TAIS Infoscopes are an integrated layer that encapsulates these files and governs their transfer between people.

Although the DAC model is possibly more flexible than the MAC based Bell-LaPadula and Biba, it suffers from a similar ailment that people and groups of people must constantly be assigned the files that they can access, leaving the potential for errors. Information must always reflect these rights for every user or group. This is costly and becomes outdated easily. TAIS is simple. Information can be dropped into Infoscopes as needed and otherwise retained in a default outer enveloping Infoscope. For example, if the US government had used Infoscopes during the Iraq war, they could have pulled compromising photos into quarantine Infoscopes before they were disseminated.

The DAC, MAC and RBAC systems pose a major communication inconvenience because they prevent people from sharing information with others who do not have the same security rights. In TAIS, a user can simply drag and drop a folder to another user without concern, because that user will simply not be able to see the information for which they or their access device is not included in the encapsulating Infoscope.

Another area of difference is that DAC, MAC, RBAC have a complex arrangement with each file having read, write or execute permissions. TAIS is much simpler than this because security is viewed purely in terms of accessibility (confidentiality). In TAIS, users can modify any file they have access to and whether they can execute it is irrelevant, because the system prevents software from affecting the host anyway. In TAIS, if you want to achieve the property of non-modification, it’s more a configuration issue, not a core security issue. Since users have their own files anyway, a read-only file scenario is achieved in two steps. Firstly, the original file is copied (hence protected) and the copy is shared to various users. Secondly, users access the file with non-editable software such as a PDF viewer. The result is a much clearer security concept – if you have access to it, then it’s yours.


[Q] How will TAIS become mainstream if Infoscopes simply prevent information from being accessed when there is insufficient authorisation in cases where the device is not trusted? How does that differ from today where systems already have multiple levels of access?

[A] TAIS is not a business model that desires mass adoption. Rather, it is purely concerned with protecting information and being able to measure the resulting deployment. From a business perspective, it is likely that TAIS will find niche opportunities in military and government and gradually extend its reach as virtualised Operating Systems provide the inter-operability that ordinary users would expect. TAIS differs from systems today that have multiple levels of access because it allows the user to be authorised at various levels and this level of authorisation gives them the capability of viewing certain levels of information. In TAIS, if a user is authorised on a low integrity device, they will still be able to move and copy highly sensitive information – they just won’t be able to see those sensitive files and folders.


[Q] It is generally understood that if something can be displayed on the screen then it can be copied, hence the problem the music and movie industries are facing. How could TAIS prevent this?

[A] The statement in the question is absolutely correct and TAIS is no exception. What TAIS does do, is prevent access to sensitive information to a device that may have monitoring software installed in it. The reason the music industry would probably find little benefit from TAIS is that they have no control over the devices that the customer utilises. Many industries such as banking also have limited capability of controlling the user device, so TAIS would also present limited use in these circumstances. However, a banking device that was tamperproof and distributed to customers would work well with TAIS.


[Q] How does TAIS differ from Common Criteria?

[A] Common Criteria is an accreditation programme that verifies that a system will always operate in a secure state. It is an expensive process and can cost up to 1 million USD to complete. There are a number of issues with Common Criteria.

     1. The time and effort to evaluate a product is so long that it may become obsolete
          before release.
     2. Updates become an issue because the system state undergoes change and must be
         reevaluated
     3. Common Criteria is extremely broad and uses a “Target of Evaluation” to cater for a
         diverse range of systems.

TAIS is different to Common Criteria and is not prey to the same pitfalls. In (1) and (2) above, accreditation is not required at the application level since the Malicious Client Problem is resolved and the TAIS system itself is a security framework. However, the TAIS emulator and execution substrate should undergo some form of accreditation. In TAIS, software loaded onto the system at any point will not affect the integrity of the deployment.

In (3) above, Common Criteria is not specific about Information Security, it deals more about System Security. TAIS targets the problem of Information Security entirely. To use an analogy, Common Criteria would be like checking an aircraft structure before the flight, but a perfectly functional aircraft doesn’t always guarantee a safe passage. In this analogy, TAIS would ensure that the pilots, weather and airport security were checked too.


[Q] How does TAIS differ from NAC?

[A] Network Access Control (NAC) attempts to unify endpoint security by making an assessment of integrity based on Operating System, Software, Patches and machine history. This is important because once a computer is allowed to join the network, they breach the firewall and automatically open a number of potential attack vectors. For example, they could connect to other computers on the same LAN that would otherwise have been off limits due to the firewall.

NAC is not an information security model, but a practical unit of armoury in the same way a bullet proof vest is not a police force.


[Q] How does TAIS avoid the classic problem of moving information from one security level to another, as presented by the Multi-Level Security or Bell-La Padula models, for example when a Top Secret file is “Sanitised” and moved to a lower level.

[A] By using Infoscopes to encapsulate information usage, different levels of security can be represented by storing information in different Infoscopes. TAIS must go through a similar process to the Bell-La Padula model, whereby the system is overridden in order to make the shift from one security level to another. In TAIS this is formalised where the owners of both the source and destination Infoscopes must agree on the information being transferred. Although this is only slightly stronger than the Bell-La Padula model, provided that the destination Infoscope prevents information leakage by specifying appropriate device access, then the information can still be locked down. At some point in the future, if the information is understood to have been leaked into a less secure zone, it can still be retrieved and pulled into the secure Infoscope.

This is a challenging problem for any security system. Consider de-sanitising a Word file that may contain hidden “Undo” data from previous edits. The data essentially must be reconstructed in a labour intensive process. A simple copy and paste could carry some of this sensitive hidden data into the lower security level.


[Q] How will TAIS become established if users must have adopted the system in order to communicate? This is the same problem of how the first person who invented the FAX would have faced when nobody had one, how does TAIS get off the ground?

[A] TAIS does not address the issue of critical mass of adoption, simply because the property of pervasiveness is not a security factor. However, it is likely that niche products such as a messaging system that allows executives from two companies to overlay a secure network across their existing independent organisation infrastructures could be useful. Such a product could be easily collapsed when it is no longer required without having to involve the two IT departments.


[Q] If TAIS aims to remove the execution substrate then every device must operate on dedicated hardware and have biometric readers in order to obtain high-end security. Isn’t this too expensive? And in the case where the execution substrate is used, what would stop key logging software?

[A] TAIS is not a theory that is designed to fix already insecure architectures, so it cannot simply be applied to systems like Windows, Linux or even the Web in order to make them secure. Instead, TAIS must be deployed with specific rules in order for it to be valid. In TAIS, the higher the desired security, the more expensive the deployment as costs to prevent machine tampering, information leakage and biometric authorisation increase.


[Q] How does the security model work?

[A] TAIS is structured as seven progressive steps that each build on the previous step. Broadly, there are three layers to the TAIS model, starting with the physical machine and ending with the secure management of information with people.

Machine Security

The machines in the network are protected by ensuring that they are not compromised upon installation and by preventing network access (on TCP/IP this involves a firewall). All software on the host should be disabled or removed from the machine. At this point, the machine is safe but useless, so an additional software unit and network connection is added depending on whether this is a thin client or core grid node.

         Thin Client

Any number of thin clients can be utilised to act as communication end points. One such thin client is the DeepReach thin client that is optimised for smartphone communication. Regardless of the thin client, it is a necessity that the data channel that separates the thin client from the node network is unable to compromise the host on which it resides. In DeepReach this is fairly straightforward since the protocol displays very basic images and other simple Scalar Vector Graphic (SVG) primitives.

         Core Grid

Securing the grid requires that the BI3 Emulator is secured against remote network attack. The mechanism for this is the same as the thin client above, but the mechanics of preventing the Malicious Client Problem is far more complex, because software and various control instructions are transmitted in the protocol that separates the peer nodes. See the expired vulnerability patent (see Downloads) by Professor Fielden for an explanation on how this is done.

Software security

Software executes on the BI3 Emulator, so it is naturally exposed to the Malicious Host Problem. One of the advantages of using TAIS is that insecure nodes can be added to the BI3 grid network, yet individual software agents executing on trusted nodes can remain secure. This is performed by encrypting transmissions between trusted agents and ensuring that the symmetric encryption key is never hosted on a non-trusted node. This configuration allows for encrypted data to be transmitted across non-trusted hosts so that the distributed software stack is not compromised.

Information security

Information is presented on the secure software layer described previously. Information is structured into Infoscopes that build on the user model by eliminating a major source of error in information sharing. Firstly, information is retained in a grid, so is not actually transmitted. Secondly, information can only be viewed if people are members of the appropriate Infoscope, but the information structures and directories can themselves be shared. As an example of usage, if a directory is copied to another person, then this person will only be able to access the files that reside in an Infoscope to which they belong. Although they can't access it, they could forward it to a person who did have access to it.


[Q] How can TAIS result in a secure implementation when software will always contain undetected faults that could be used to launch an attack by hackers to break into the system. How does TAIS address these practical realities of software development?

[A] A great question. Lets identify the vulnerabilities that can occur. The software written to run on TAIS systems cannot induce a vulnerability because that client software is pre-scanned to ensure that it has zero dependencies (no library calls) when implemented in software (lets consider the software case here only because this is your question). This inability to affect other TAIS processes, the TAIS Emulator or the substrate (if it exists) is a solution to the Malicious Client Problem. Zero dependencies would otherwise make the software fully introspective and effectively useless, but a 'safe' communication method required by TAIS called the Reference-Membrane and Context-Reduction-Engine enables communication without vulnerabilities. However, preventing vulnerabilities from residing in the TAIS Emulator itself (as opposed to software running on the TAIS Emulator) is another problem altogether. TAIS addresses this in 2 ways. (1) the architecture is relatively simple when compared to modern day Operating Systems and so the number of lines of code is much less and analysis much easier, and (2) there is no direct network access to the substrate or TAIS emulator itself, so direct remote attacks are not possible. Other than this, TAIS requires that the machine must adhere to the specification and any deviation will accumulate Design-Time Factor risk. Since there is a much smaller attack surface area (which doesn't change as new programs are loaded) the integrity of the TAIS Emulators can be proved secure or the risk assessed during accreditation.


[Q] How can TAIS be applied in practice? Is it like anti-virus? How could this technology be used by IT today?
- Question by Shen Hongkang

[A] Since TAIS is a general theory of security, it cannot be applied directly in an information system. There are a number of intermediate stages that need to occur. Firstly, a design specification must be drawn up (such as the BI3). From this design, software can be constructed or a hardware circuit manufactured such as in Field Programmable Gate Arrays (FPGA fabric). If it is a software solution, then it will need to execute on some supporting substrate such as Windows or Linux. During this process all the abstract design criteria must be resolved (covered later, also review the BI3 specification for how this is done). Resolving criteria of abstraction means that before BI3 Emulator can operate, everything unspecified or abstract needs to be ultimately defined exactly. Resolution is a complex process, but the BI3 specification and bluebrick™ Java implementation is an experimental research deployment that demonstrates the resolution process. There are no known commercial implementations ready for securing IT infrastructure (as at 2011), but there may well be within a few years.

To answer this question in another way, the TAIS approach is a clean-slate design in that it foregoes backward compatibility for security. This means that information must be transferred onto the TAIS deployment and won’t run directly. Windows systems will need to execute through emulation of a PC that runs on the TAIS deployment. It is not like anti-virus in any way because it does not aim to correct faults on flawed computing architectures. Rather, it aims to prevent fault altogether by using an alternative approach.


[Q] Manufacturing companies that develop the hardware on which TAIS will be loaded are similar to how Windows comes pre-installed on generic PCs and laptops. In this comparison, manufacturers of hardware specific to Windows have a clear idea of the software that will be loaded onto their machines and so can design the hardware accordingly but if the TAIS specs are too vague then it will be problematic for manufacturers to produce hardware for its use; so therefore developers would have to build the TAIS implementation around the hardware. Am I on the right track?

-Nick Schofield


[A] This a great question because it highlights the nature of TAIS as a theory. You are absolutely right in your question, hardware manufacturers could not produce (meaningful) hardware based on TAIS alone. We need a specification which resolves the criteria of abstraction such as the BI3. The abstract concepts found in TAIS are fully undefined, for example, TAIS Alpha 1a states “The execution substrate of the TAIS Alpha Environment is not compromised”. Clearly, this isn’t enough for manufacturers. Therefore a specification must clear this up. Some specifications like the BI3 still have some abstract components that must be resolved during implementation – but the range of architectural possibilities is contained to enable interoperation regardless of the implementation choice. The TAIS model really highlights how this is a continuous scale from abstract theory to concrete specification and there are a great variety of positions that an architectural description can take along that scale. This is very common in the Object Orientated methodology, which allows total freedom of abstraction, provided all abstract methods are implemented prior to linking. The reality is that in both hardware and software, before anything can exist and execute (operate), somewhere the exact manifestation will need to emerge.


[Q] How can it be possible to prevent a remote party from engaging a passive attack that takes advantage of flaws or backdoors in software simply by using a Context-Reduction-Engine and Reference-Membrane? Surely, there must be some scenario for which this defence configuration won’t hold true and an attack can be made? For example, let’s say that a military contractor is actually a double agent working for the enemy and has developed code that activates a backdoor when a certain condition is met – let’s say when the code processes the user name “John Andrew-Jackson Smiley”?

[A] The TAIS Beta Environment (TBE) locks down the capabilities of the military contractor’s code as follows:

1. It cannot make any library calls
2. It cannot reference anything outside of itself
3. It must communicate with a minimal set of narrow instructions

The Context-Reduction-Engine (CRE) is more secure when there are fewer Context-Handlers and each is narrow and safe in scope. In an ideal implementation, the contractor’s code resides in a TBE process that has no knowledge of any previous instruction. Its capabilities are limited to the list of Context-Handlers available in the CRE and the developer’s TBE process can’t make a connection to another computer to disseminate information.

To reduce the TSR, the number of Context-Handlers must be reduced (5@B3b) and the scope of the Context-Handlers themselves reduced (2@B3b). A low risk for non-trusted code can be achieved by outsourcing a series of a modular functions that each operate independently with customised CREs for their specific requirements. A high TSR could occur in an implementation that built a broadly functional application that accessed multiple generic CREs with many Context-Handlers that were not required by the process.



   About a Blueicon    FAQ    Research    Ethical Hacker Challenges    Downloads    Hall of Fame    Contact    Demo    Forum