The passing of the Telecommunications and Other Legislation Amendment (Assistance and Access) Act 2018 (Cth) on 6 December 2018 creates an additional avenue for Australian law enforcement and intelligence agencies to request or compel "Designated Communications Providers" (DCPs) to provide access to otherwise encrypted communications, with significant implications for businesses involved in the tech sector.
If you are a foreign or domestic entity involved in some way with the tech or telecommunications industries in Australia, you may be requested or compelled to give assistance to Australian law enforcement and intelligence agencies, and you should understand what actions you may or may not be required to take. You should also be aware that other entities in your supply chain may be subject to similar requests. Each of these facts pose risks for your business.
You should also develop clear internal processes for responding to requests/notices, and understand your compliance obligations and appeal rights under the Act.
Does the Assistance and Access Act apply to me? Almost certainly.
The Act applies to "DCPs", which captures almost everyone involved in a telecommunications supply chain with end-users in Australia.
This ranges from large players, such as carriers and carriage service provider (such as telephone and internet access services) right through to persons who connect customer equipment to a telecommunications network.
It also captures internet service providers and those who provide "electronic services", including (according to the EM) "websites and chat fora, secure messaging applications, hosting services including cloud and web hosting, peer-to-peer sharing platforms and email distribution lists" with one or more end-users in Australia.
The Act also captures everyone in between, including:
- software developers and suppliers connected to a carriage or electronic service, for example persons involved in designing software used in secure messaging applications;
- persons who provide services that facilitate/are ancillary to the provision of either an electronic service or carriage service;
- persons that manufacture, supply, install, maintain or operate a "facility", meaning "any part of the infrastructure of a telecommunications network or any line, equipment, apparatus, tower, mast, antenna, tunnel, duct, hole, pit, pole or other structure or thing used, or for use, in or in connection with a telecommunications network"; and
- persons that manufacture or supply customer equipment for use, or likely use, in Australia, including mobiles, modems and computing devices, as well as those who manufacture equipment such as "circuit boards, subscriber identification modules (SIMs) or memory units of a mobile device".
The Act will also capture third parties such as "technical experts or contractors installing or maintaining customer equipment provided by a manufacturer, supplier or retailer, such as managed service providers" and those providing ongoing maintenance "or persons acting at the point of installation".
So what does the Assistance and Access Act mean for me?
It means that any of the above persons, including in your organisation and/or entities in your supply chain can receive a request or be compelled to assist law enforcement/intelligence agencies to provide access to otherwise encrypted communications, or build/implement a new capability in an area relevant to your business.
What can we be asked to do?
What a DCP is actually required to do will depend on the type of notice or request received (being either a Technical Assistance Request (TAR), a Technical Assistance Notice (TAN) or Technical Capability Notice (TCN)).
However, broadly this assistance could be in the form of:
- decrypting communications where a DCP already has the ability to do so;
- installing agency software of the DCP's network;
- modifying the characteristics of a service or substituting a service provided by the DCP;
- facilitating access to the relevant facility/equipment/device or service;
- handing over technical information such as "source code, network or service design plans, and the details of third party providers contributing to the delivery of a communications service, the configuration settings of network equipment and encryption schemes"; or
- '"concealing the fact that agencies have undertaken a covert operation".
While compliance with a technical assistance request is voluntary, compliance with a technical assistance notice and TCNs is mandatory, with non-compliance attracting substantial civil penalties.
A service provider in our supply chain has received a notice – will we be told about this?
Not necessarily. The operation of the secrecy provisions under the Act mean that unless one of the exceptions is enlivened, there is no guarantee that you will even know that a DCP in your supply chain has received a request/notice. This is because (subject to exceptions) it is an offence under the Act to disclose information about a request/notice, including (as the Law Council of Australia pointed out in its submission) "the mere existence of the requests or notices", with a penalty of up to 5 years' imprisonment. Further, this secrecy provision applies not only to the DCP, but also a DCP's employees, a contract service provider of a DCP, and employees of the contracted service provider of a DCP. Additionally, only the relevant "provider" needs to be consulted before a notice is issued, not everyone who is affected by the request or notice.
Can we appeal a decision to issue us a notice?
It depends. Decisions made under Part 15 will not be subject to review through the ADJR Act, nor are they made by a judicial officer. However, judicial review through the original jurisdiction of the High Court or Federal Court of Australia by operation of section 39B(1) of the Judiciary Act 1903 (Cth) is still available.
Also, if you receive a consultation notice relating to a TCN requiring you to build a new capability, you can request that the TCN is assessed to determine whether it should have been given. This assessment will be conducted by two assessors, including a technical expert and former judicial officer. While this offers slightly more oversight in relation to TCNs, and judicial review will still be available through the courts, the Act nonetheless removes key elements of judicial oversight over the decisions made under the Act.
What are the limitations on the power to issue requests/notices under the Act?
There are some restrictions on the use of the power to issue requests/notices under the Act.
Decision-making criteria
In issuing a request/notice, the relevant decision-maker must be satisfied that the request itself or the requirements imposed by a notice are
- reasonable and proportionate; and
- that compliance is practicable and technically feasible.
In considering whether a request/notice is reasonable and proportionate, the decision-maker needs to consider a variety of factors, including national security; the legitimate interests of the DCP and expectations of Australian community re: privacy and cybersecurity; the availability of other means to achieve objectives; and whether the request is necessary. Once the decision-maker is satisfied of these matters and decides to issue a request/notice, your rights to appeal that decision are limited.
Limitations on extent of assistance and interaction with privilege
A TAR, TAN or TCN must not have the effect of requesting or requiring the implementation or building of a "systemic weakness" or "vulnerability" into a form of electronic protection or preventing providers from fixing an identified weakness or vulnerability.[1] The Act also does not affect the law relating to parliamentary privileges and immunities.
Compensation and immunity
In complying with a request/notice, as a DCP you will be compensated for "reasonable costs" incurred, (although what this will actually cover is unclear), and are immune to civil liability for acts done in good faith with a notice or request.
However, this immunity only protects you in Australia: it does not protect you from civil actions in foreign courts if complying with a notice or request causes you to breach foreign laws. For instance, a notice that required access to the data of European Union citizens could amount to a breach of the EU's General Data Protection Regulation if complied with.
Further, this immunity does not protect others in the supply chain. Telstra gave the example of a party in a supply chain being required by a notice to modify a telecommunications network, and causing a system fault or service degradation as a result. In these circumstances, the telecommunications provider would not be afforded any civil immunity. Additionally, as Senetas pointed out in its submission, the secrecy provisions would "prevent all parties from even explaining the cause of the failure," or assisting the provider to fix it, with potentially significant financial and reputational consequences.
What happens now?
The draft Bill received significant pushback from a range of stakeholders, with overarching concerns that weakening encryption would weaken internet security and increase the vulnerability of Australians and Australian assets. Concerns were also raised about the Act's impact on Australia's IT export industry, with comparisons being drawn between the rejection of Huawei as a 5G provider due to perceived risks of government-compelled disclosure of private communications, and the risk that Australian vendors would now be viewed with similar suspicion in overseas markets, a comparison that was rejected by the Director-General of the ASD, Mike Burgess.
A legislative review by the Independent National Security Legislation Monitor is scheduled to be held within 18 months of the Acts commencement, together with a review by the Parliamentary Joint Committee on Intelligence and Security in early 2019. The Federal Opposition has also stated it will seek amendments to the Act, offering a potential opportunity for stakeholders to reiterate their concerns and seek improvements. However, in the meantime the Act will apply in its current form, and DCPs need to be ready to meet their obligations accordingly.
[1] Under section 317B, a systemic vulnerability is defined to mean "a vulnerability that affects a whole class of technology, but does not include a vulnerability that is selectively introduced to one or more target technologies that are connected with a particular person. For this purpose, it is immaterial whether the person can be identified." Back to article