In many democratic countries, Communications Assistance for Law Enforcement Act (CALEA) wiretaps are used by law enforcement agencies to perform investigations and gather evidence for legal procedures. However, existing CALEA wiretap implementations are often engineered with the assumption that wiretap operators are trustworthy and wiretap targets do not attempt to evade the wiretap. Although it may be possible to construct more robust wiretap architectures by reengineering significant portions of the telecommunications infrastructure, such efforts are prohibitively costly. This paper instead proposes a lightweight accountable wiretapping system for enabling secure audits of existing CALEA wiretapping systems. Our proposed system maintains a tamper-evident encrypted log over wiretap events, enforces access controls over wiretap records, and enables privacy-preserving aggregate queries and compliance checks. We demonstrate using campus-wide telephone trace data from a large university that our approach provides efficient auditing functionalities while incurring only modest overhead. Based on publicly available wiretap reporting statistics, we conservatively estimate that our architecture can support tamper-evident logging for all of the United States’ ongoing CALEA wiretaps using three commodity PCs.
Legally authorized wiretaps are conducted in every democratic country in the world. Generally approved by some external judicial process, sanctioned interception allows law enforcement to gather information about call activity related to potentially illicit activities. The information generated by this process is both extremely valuable and sensitive, making its protection of paramount importance.
Like any other process that creates or manages important data, the ability to audit wiretaps is critical. Verifying the correctness of such data not only gives the public better protection against abuse and greater confidence in the process, but also provides law enforcement agencies with stronger guarantees for their evidence. However, because the existence of a wiretap is itself a secret, providing verifiable evidence that legal interception was correctly conducted and logged is difficult.
In this paper, we propose an accountable wiretapping architecture that enhances wiretapping systems by adding tamper-evident records of wiretap events. In addition to the standard wiretap channel to law enforcement agencies (LEAs), we introduce Encryptor devices that interpose on the output of CALEA switches. Encryptors transmit encrypted wiretap records to an external wiretap log storage provider, referred to as the “Log”, that stores the encrypted wiretap data and performs on-demand audits over the encrypted records. The Log allows auditors such as a supervising court, a justice department, or an NGO, to reconcile events captured by LEAs with those in the Log. Our threat model considers three potential adversaries: (i) the target of the wiretap who employs known denial-of-service attacks to overwhelm the wiretap’s resources [44], (ii) a malicious employee of the service provider who wishes to undetectably perform an unauthorized wiretap using the CALEA APIs, and (iii) a dishonestLog that attempts to learn information about current and/or previous wiretaps. We demonstrate that under our reasonable assumptions, our auditing system detects the former two attacks and provides privacy mechanisms to limit the unauthorized exposure of wiretap information against the third.
This paper makes the following contributions:
Proposes methods for detecting attacks against the CALEA infrastructure: A number of recent papers have demonstrated potential vulnerabilities in the wiretapping infrastructure [43,44]. However, research in this area is largely outside of the public’s purview. Our work represents the first public effort to improve both confidence and accuracy of legal telephony interception.
Introduces system and associated protocols to enable trustworthy wiretap auditing: We introduce a threat model for accountable wiretapping, and argue that existing wiretap collection and retention services do not adequately protect the integrity of wiretap records. We describe protocols for performing efficient auditing, reporting and compliance verification over encrypted wiretap records. In particular, we present protocols for protecting the confidentiality of wiretap records and providing tabulation and proofs of completeness to an auditor. These protocols are deployed in distributed architecture that forms a minimal-impact retrofit for current interception systems.
Evaluates implementation through extensive performance study: We build a proof-of-concept implementation of our auditing infrastructure and conduct a range of performance benchmarks. We measure our system using anonymized call data from a major university. Based on the reported number of CALEA wiretaps [13], we estimate that our system could accommodate all U.S. wiretaps on 3 commodity machines.
Introduce microauditing procedures to enable real-time assurance of audit goals: In our conference version of this paper, we assumed that wiretap record auditing is an infrequent offline cost [3]. Leveraging the properties of the history tree data structure [12], we create online audit protocols that facilitate frequent challenges of wiretap record Integrity, Completeness, Date Compliance and Reporting. In exchange for a manageable increase in record insertion cost, these new procedures create upwards of a 99.8% speed improvement for trustworthy wiretap auditing; for example, court audit speed improves from 0.2 audits per second to 312 audits per second.
The rest of this paper is organized as follows. In Section 2 we review lawful access as well as the CALEA architecture and its known vulnerabilities. We define the requirements of an accountable wiretapping system in Section 3. In Section 4 we present our protocols for secure logging and auditing of wiretap records. A security analysis of our architecture and protocols follows in Section 5. Section 6 evaluates the performance of a proof-of-concept accountable wiretapping implementation. In Section 7, we present an optimized set of microaudit protocols that enable auditing challenges to efficiently run in parallel with regular call interception. Related work is discussed in Section 8, and we conclude in Section 9.
Background
This paper makes the distinction between lawfully authorized surveillance and illegal eavesdropping. The latter is a much more widely understood threat: an eavesdropper surreptitiously observes some traffic and attempts to learn the content of the communication and/or the identities of the communicants. The problem of illicit eavesdropping has been well studied, and eavesdropping tools as well as countermeasures are readily available. In contrast, lawfully authorized wiretaps are subject to legal constraints. Courts, or in some instances a law enforcement agency, must approve of the wiretap.
Wiretaps can be divided into two classes: Pen register/trap and trace (“pen/trap”) devices record call information such as call establishment, call disconnection, call waiting, call redirection and dialed digits. Pen register devices record the metadata related to outgoing calls; trap and trace devices do the same for incoming calls. Neither system records call content. In the United States, the requirements for obtaining pen/trap wiretaps are much lower than that for content wiretaps: law enforcement agencies (LEAs) need only assert that metadata is pertinent to an ongoing investigation [52].
The second class, Content wiretaps, capture both call metadata and call content. In many jurisdictions, LEAs must convince a court that they have a reasonable belief that a target has committed a crime (i.e., “probable cause”). In the U.S., pen/trap orders are more common than full content wiretaps. For example, 20,899 pen/trap orders [51] and 386 content wiretap orders [13] were authorized in 2008. For both pen/trap and content wiretaps, the wiretapping is carried out by technicians employed by the service provider. Wiretap data are then transferred in real-time to a listening post maintained by a law enforcement agency.
Despite the importance of wiretap evidence to investigators and the courts, there are only a few publicly available and impartial studies of wiretap systems and architectures [25,43,44]. In part, this is because conducting an academic study of wiretap systems is complicated by legal constraints and business practices. Wiretap systems are often closed-source “black boxes” with little publicly available information, and manufacturers often provide technical specifications only to law enforcement organizations. In the U.S., the possession of wiretap equipment by non-law enforcement personnel is generally prohibited and punishable by up to five years in prison [52].
The inability to properly study deployed wiretap systems gives an advantage to those who wish to circumvent them; those who intend to illegally subvert a surveillance system are not usually constrained by the laws governing access to the wiretaps. Indeed, the limited amount of research that has looked at wiretap systems [43] and standards [44] has shown that existing wiretaps are vulnerable to unilateral countermeasures by the target of the wiretap, resulting in incorrect call records and/or omissions in audio recordings.
It has recently been argued [39] that wiretapping architectures can be made more robust by, for example, mandating that traffic flow through centralized “interception points” and imposing key escrow for all encrypted communication. There are significant technological and economic costs and risks [6,25] associated with such a massive re-architecting of our communications networks. Modification would likely require billions of dollars. As legal wiretaps make up a small faction of all communications, re-engineering the system to improve wiretap capabilities is impractical and costly.
CALEA wiretap architecture
The 1994 U.S. Communications Assistance for Law Enforcement Act (CALEA) [11] requires telecommunication service providers to incorporate wiretapping functionality into their switches. Previous wiretap architectures relied on the physical cloning of wireline connections. The growth of cellular communication led to the promotion and eventual adoption of the newer and more flexible CALEA wiretapping architecture. The CALEA law seeks to standardize methods and protocols for conveying wiretap information from providers’ switches to law enforcement agencies. A major impetus of the Act was to standardize wiretap processing for new service offerings – in particular, cellular voice and data services. In 2003, telecommunication industry associations with input from law enforcement officials published ANSI Standard J-STD-025 (commonly referred to as the “J-Standard”) [46], a collection of deployment guidelines and protocol specifications for communicating wiretap data to LEAs. Somewhat confusingly, “CALEA” is often used to refer to both the U.S. law regarding wiretap requirements as well as the J-Standard systems that are used by several countries to conduct wiretapping.
CALEA wiretap architecture. Solid arrows indicate standard telephony communication. Dashed arrows denote CALEA wiretap traffic flows. (Colors are visible in the online version of the article; https://dx-doi-org.web.bisu.edu.cn/10.3233/JCS-140515.)
An overview of the CALEA wiretap architecture is presented in Fig. 1. Each subscribed service (e.g., landline phone, cellular, etc.) connects to the service provider through a switch located at the subscriber’s central office. The switch relays the user’s communication to and from the rest of the telephone network (solid lines). If the subscriber is also a target of a wiretap, then the CALEA-compliant switch also sends a copy of the traffic to a Delivery Function (DF). Located at the service provider, the DF collects wiretap information from the switches and transfers it via J-Standard defined protocols to the LEA (dashed lines). We note that the last-mile connection between a mobile phone and the switch is actually considerably more complex. Conceptually, voice and data packets are routed via a Mobile Switching Center to the subscriber’s central office. For clarity, Fig. 1 omits these extra hops, which are orthogonal to the operation of the wiretap. We note also that service providers maintain many such central offices, and a typical central office may serve a few thousand customers.
Call metadata (e.g., the identities of the communicants) are relayed via separate channels than call content to the LEA. The DF combines all sources of call metadata that are associated with a given wiretap, and encodes the information using the Lawfully Authorized Electronic Surveillance Protocol (LAESP) that is defined by the J-Standard. Metadata from different services (landline telephone, cellular, etc.) are multiplexed over the same call metadata channel between the DF and the LEA. LAESP protocol headers identify the pertinent wiretap order as well as the switch that captured the call event. The J-Standard also permits call metadata events belonging to different wiretap orders to be multiplexed together over the same call metadata channel, so long as they are associated with the same LEA.
In the case of content wiretaps, the DF creates one or more call content channels between itself and the LEA. Unlike the call metadata, call content is not multiplexed – each intercepted service is allocated with its own dedicated call content channel. Intercepted content communication is typically copied verbatim and transferred over the call content channel.
Vulnerabilities in CALEA wiretaps
Previous work has shown that CALEA wiretaps are vulnerable to target-initiated DoS attacks [44]. Although the J-Standard does not mandate a particular type of connection between the DF and the LEA, it recommends using a 64 kbps ISDN B line for each call content and call metadata channel. The target of the wiretap may overwhelm the 64 kbps connection by purposefully inducing a high rate of call events. For example, in the case of content wiretaps, six LAESP messages are sent via the call metadata channel whenever the subject attempts and aborts a phone call, consuming 1.3 kB of bandwidth per attempt. Telephony services which enable the target to attempt more than 6.2 calls per second (as is the case for VoIP services) permit the target to overwhelm the 64 kbps capacity of the call metadata channel. Additionally, the target may apply other signaling techniques (e.g., rapid ISDN feature key selection) to similarly exhaust the call metadata channel. (Recall that the DF multiplexes signaling information from multiple services over the same call metadata channel, improving the target’s ability to conduct DoS attacks.) Since the call metadata channel carries control messages which indicate the start and end times of audio content [46], its exhaustion may also lead to gaps in content recordings [44].
Accountable wiretapping
There is little publicly available information regarding the operation and features of existing CALEA wiretap implementations. Manufacturers often closely guard the operation, security features, and limitations of their wiretap systems. However, the product white papers and manuals that are accessible [9,10] indicate that wiretap systems perform little logging. In part, this is by design: the existence of a wiretap is considered sensitive information. Preventing a (potentially rogue) technician from enumerating all past and present wiretaps reduces the risk that wiretaps become exposed.
This paper argues that wiretap events can be logged in a privacy-preserving manner, enabling secure audits of CALEA wiretaps. There are unfortunately no previously defined or well-established security requirements for conducting auditable wiretaps: neither the J-Standard nor any product literature of which we are aware describe technologies for conducting audits. Similarly, U.S. and European law do not appear to consider an audit process.
We note that at least one company advertises collection and retention services that can be used in a wiretap audit [54]. However, their product receives cleartext wiretap information from service providers, and is therefore inherently trusted with such data. In contrast, our architecture assumes a potentially untrusted logging service, and ensures that the Log (i) never obtains access to plaintext wiretap records, (ii) cannot determine the number or scope of wiretaps, and (iii) can provide proofs to the auditors that it has correctly recorded all (encrypted) data. Given the sensitivity of wiretap data and the ease at which trusted systems may become compromised, we argue that the storage service should be modeled as an untrusted participant.
Security goals
Our accountable wiretapping system aims to achieve the following audit goals:
Integrity:
A wiretap audit should identify modified or corrupted wiretap records. Formally, if are the wiretap records belonging to wiretap W that are sent by the service provider between times , and are the wiretap records received by the LEA that purportedly belong to W within times , then the audit should identify the true wiretap records .
Completeness:
A wiretap audit should identify gaps in the records collected by the LEA. Given the above definitions of L and , the audit should determine whether . Note that this definition of completeness encompasses the scenario in which .
Date Compliance:
A wiretap-granting authority authorizes a wiretap for a date range. The audit process should determine whether events were captured outside of that range. That is, given a date range and a wiretap event τ, the audit should reveal whether the interception of τ occurred within .
Importantly, the audit goals are sufficient to detect the DoS attacks described in Section 2.2: An auditor can detect LAESP messages that have been corrupted or lost due to target-initiated signaling attacks by verifying the wiretap records’ Integrity and Completeness.
Additionally, our audit process should support the efficient collection of information for legally mandated wiretap reporting requirements. The Omnibus Crime Control and Safe Streets Act [52] requires the Administrative Office of the U.S. Courts to present an annual wiretap report to Congress. The report includes the number of new and expiring pen/trap and content wiretaps. European nations have similar reporting requirements (e.g., England’s Regulation of Investigatory Powers Act of 2000 [7]). Although U.S. law requires the Attorney General to separately report the number of pen/trap and content wiretaps, the number of pen/trap wiretaps has not regularly been disclosed. U.S. Public Law 106-197 additionally requires the AO to report the number of times that law enforcement detected that the target’s communications were encrypted [53]. Interestingly, encryption does not seem to be widely applied: the 2010 Wiretap Report discloses only six instances of encryption, and notes that this “…did not prevent officials from obtaining the plain text of the communications.” [14]. Towards achieving compliance with these reporting requirements, our architecture supports the following accounting goal:
Reporting:
The audit should accurately report the number of new pen/trap wiretaps, new content wiretaps, expiring pen/trap wiretaps, and expiring content wiretaps within a specified time interval .
By reconciling with law enforcement and court records, the Reporting functionality can also be applied to detect unauthorized wiretaps (i.e., a content or pen/trap wiretap that has not been authorized by a court or law enforcement agency, respectively). In addition to detection, an audit process that supports Reporting allows the auditor to issue repeated requests to discover the time that the illegal wiretap was initiated.
Our proposed system is a first step in developing more accountable wiretap systems. As such, we do not prevent attacks similar to the “Athens Affair” [35] in which telephony switch software was directly modified by an insider. We believe that our model is still powerful, especially considering that most other security infrastructure also fails when an adversary gains direct access to a machine. Additionally, our current system only considers pen/trap orders and not content wiretaps. As Pen registers represented 98% of total U.S. wiretap orders in 2008 [13,51], our system already achieves our security audit goals for the vast majority of wiretaps.
Architecture and participants
Our proposed audit process is designed to augment existing CALEA deployments without requiring significant (and costly) modifications at the service provider. In particular, our solution introduces a single component – the Encryptor – at the provider’s central office.
Recall that the Delivery Function (DF) collects wiretap information from various switches located at the central office, and transmits call metadata and (optionally) call content pertaining to a wiretap to a LEA (see Fig. 1). In our accountable wiretapping architecture, the DF is configured to also send a copy of wiretap events to the Encryptor. Located at the service provider, the Encryptor encrypts wiretap events and transfers them to an off-site storage facility called the Log (see Fig. 2, left). The Log is an untrusted repository of encrypted wiretap events whose purpose is to archive wiretap data and assist in the audit process. Unlike commercial wiretap data retention stores [54] which share a similar architecture to our design, the Log does not have access to plaintext wiretap information and cannot enumerate the wiretaps.
Wiretapping audit workflows. Left: The Encryptor transfers encrypted copies of wiretap records to the Log. Center: A court auditor requests wiretap records from the Log. Right: An accountant gathers coarse-grained statistics about collected wiretaps.
The Log may store data from multiple wiretaps and possibly from multiple telecommunications service providers. By outsourcing the burden of wiretap audits away from service providers, the Log assumes the responsibilities of data maintenance and retention while providing a small barrier to participate: From the perspective of the DF, the Encryptor operates as a sink, collecting call metadata and content as would a downstream LEA. In turn, the Log operates as a database of auditable wiretap records. Although the Log is not trusted, we argue below that our architecture ensures that insertions, modifications, or omissions of wiretap events will be detected during an audit.
Finally, we assume the existence of a trusted Wiretap Authority (e.g., a court) that authorizes the service provider to conduct the wiretap.
Audit types
Our architecture provides support for two types of audits. In a court audit, the auditor queries the Log for all records pertaining to a particular wiretap (see Fig. 2, center). For simplicity, we refer to this authority as a court, although in principle a court audit could be conducted by a non-judiciary body (e.g., a Justice Department). A court may be authorized to audit one or more wiretaps (for example, the wiretaps it previously issued), but cannot learn any information about the wiretaps for which the Wiretap Authority has not granted it access. Court audits may be appropriate, for example, to ensure (via the Integrity and Completeness properties) that all wiretap events were correctly captured by a LEA. Such audits are also useful to detect target-initiated DoS attacks against CALEA (see Section 2.2).
In an accounting audit, an accountant gathers statistics from the Log regarding the total number of pen/trap and content wiretaps (see Fig. 2, right). The accountants are restricted to coarse-grained data: they should not learn any information regarding individual wiretap events during an accounting audit. However, the accountants can compile statistics over all the wiretaps stored at the Log.
Note that both the court auditor and the accountant are trusted. In the former case, the court auditor is the judicial authority; if malicious, such an authority does not need to circumvent the wiretap audit in order to corrupt the judicial process. Similarly, since accountants are already tasked with compiling and reporting wiretap figures, they can simply provide false results. That is, the justice system already implicitly trusts the court to behave honestly and wiretap tabulators to report accurate statistics; our architecture assigns similar trust. As we describe next, we must still be able to detect any malicious behavior by the untrusted Log.
Threat model
The overarching goals of our accountable wiretapping infrastructure are tamper-evidence, compliance with reporting requirements, and privacy: Modifications, insertions, or omissions of wiretap records by the Log should be detectable, and no auditor should have access to either coarse- or fine-grained wiretap information to which the Wiretap Authority has not explicitly granted it access.
We model three adversaries:
Wiretap target: The target of the wiretap may attempt to cause denial-of-service against the wiretap by overwhelming the call metadata channel between the Delivery Function (DF) and the LEA. The target can generate a high frequency of wiretap events (potentially using different devices), causing the resultant LAESP messages to consume the channel’s bandwidth [44]. A goal of our architecture is to maintain a complete (Completeness) and accurate (Integrity) record of wiretap events, enabling court auditors to discover the resulting gaps in the transcripts collected by LEAs.
Unauthorized wiretappers: We provide some protection against attackers who provision unauthorized CALEA wiretaps. Such attackers may include rogue employees of the service provider or overzealous law enforcement officials. As discussed above, we do not protect against all forms of data exfiltration; unencrypted data flows throughout the phone system, and e2e solutions that protect against interception along these points would require a costly reengineering of the existing communications infrastructure. Instead, we focus on attackers who use the DF’s built-in functionality to conduct unauthorized wiretaps. We assume that all wiretap events are captured by the Encryptor.
An accountable wiretap system that achieves the Reporting property ensures that such unauthorized wiretapping will be detected during accounting audits, since audit results can be reconciled with records maintained by the Wiretap Authority.
Dishonest Log: As described above, the Log receives encrypted wiretap records from the Encryptor. A dishonest Log may attempt to corrupt court or accounting audits by modifying or deleting these records or by inserting false records. Additionally, the Log may attempt to circumvent the privacy properties of our proposed architecture by either learning the plaintext of the encrypted wiretap records or by discovering timing information about wiretap events.
Our architecture is designed to provide both confidentiality (the Log cannot decipher encrypted records) and unlinkability (the Log cannot determine that two encrypted records belong to the same wiretap). The former ensures the privacy of wiretap events, while the latter aggravates timing analysis.
Additional network and trust assumptions
As discussed above, we assume that court and accountant auditors are correct and obey our protocols. (We do, however, prevent a court auditor from learning any information about wiretaps to which the Wiretap Authority has not granted it access.) We further assume that the service provider is honest. In particular, the DF generates actual wiretap events (either legally authorized or not) and the Encryptor behaves correctly and does not release key material. The Encryptor captures all wiretap events output by the DF. Ideally (but not necessarily), the connection between the Encryptor and the Log should be adequately provisioned to prevent loss. As discussed in Section 4.3, our architecture detects such losses, but cannot distinguish between transmission loss and the Log’s purposeful omission of wiretap records. Finally, we assume that the Encryptor has an accurate clock.
Protocol
To protect the confidentiality of wiretap records, the Encryptor encrypts records with a symmetric key known only to itself and a court auditor (recall that the accountant is not authorized to access individual wiretap records). Additionally, to enable the court auditor to detect inserted or modified records, the Encryptor digitally signs each message before it is sent to the Log. Handling omissions in a court audit is slightly less straightforward, and relies on the Encryptor’s inclusion of encrypted sequence numbers as well as periodic heartbeat messages. A court auditor, who can decrypt the sequence numbers, can detect omissions between reported wiretap events by locating gaps in the sequence numbers. The use of regularly scheduled heartbeat messages bounds the Log’s ability to omit records at either end of the audit – that is, messages can be deleted, but the omission of the heartbeat indicates tampering, as do gaps that occur before or after the heartbeats.
To support accounting audits, the Encryptor encrypts counters along with each record using an additive homomorphic encryption scheme. Here, counters capture the number of new and expiring wiretaps, enabling the Reporting property. During an accounting audit, the Log computes the sum over the counter ciphertexts and sends the result to the accountant. The accountant, who possesses the private key, can then decipher the result. The use of digital signatures and nonce summations (explained in Section 4.3) enables the auditor to verify the Log’s results.
Keying
The Wiretap Authority (“Authority”) authorizes the service provider to conduct a wiretap, and is responsible for generating and disseminating cryptographic keys. To ensure authenticity, integrity, and non-repudiation of wiretap events, the Authority generates an authenticity keypair and securely shares the signing key with the Encryptor. For each wiretap, the Authority provides the Encryptor with a single symmetric key r (the record key) used to encrypt wiretap events. The Authority also designates a validity period over which the wiretap is authorized, and shares with the Encryptor. Finally, the Authority creates an aggregation keypair and gives to the Encryptor. The use of the aggregation keypair is explained in Section 4.2.
During the course of a court audit, the Wiretap Authority shares r with the court auditor. For accounting audits, the Authority shares with the accountant. The public key used for verifying the Encryptor’s signatures is public, and we assume all auditors have knowledge of this public key (e.g., through a certificate signed by the Authority). Note that the Log does not know any of r, or . A summary of the keys used by our protocol is presented in Table 1.
Summary of keys
Key
Description
Assignment
Knowledge
r
Record key. Encrypts wiretap records (either call metadata or content).
Per wiretap
Encryptor, Court Auditor
Public authenticity key. Enables authenticity and integrity checking of wiretap records.
Per Encryptor
All parties/Public
Private authenticity key. Enables authenticity and integrity checking of wiretap records.
Per Encryptor
Encryptor
Public aggregation key. Encrypts wiretap statistics.
Notes: The Assignment column indicates whether the key varies between wiretaps (“per wiretap”) or is common to all wiretaps protected by the Encryptor (“per Encryptor”). The Knowledge column indicates the parties who possess the key. We denote symmetric and asymmetric keys respectively in lowercase and uppercase.
Event logging
The Encryptor collects events from the Delivery Function (DF), encrypts them, and transmits the ciphertexts to the Log. The Encryptor maintains minimal state, storing only the record key and the private authenticity and aggregation keys, as well as a per-wiretap event counter.
In this section, we describe our protocol for ensuring confidentiality and unlinkability (the Log cannot discover the plaintext records, nor can it enumerate wiretaps or link records as belonging to the same wiretap). The correctness of audit results (i.e., Integrity, Completeness, Date Compliance and Reporting) are argued in Section 5.
Let be a continuous stream of wiretap events produced by the DF. Note that the stream may include events pertaining to multiple wiretaps. We let be the ith event of this sequence, and define to be the time that the Encryptor received from the DF. Without loss of generality, we denote the wiretap that produced as w and the Encryptor’s event counter for w to be . The event counter is incremented by one whenever the Encryptor transmits an event belonging to wiretap w.
The Encryptor prepares the message
where denotes concatenation, E is an IND-CPA cipher, is the encryption of Q using symmetric key r, is a cryptographic checksum over its input, and is an aggregation block which is described below. The Encryptor sends
to the Log, where is a digital signature over message Q using key . Upon receipt, the Log stores the message.
Aggregation block
The aggregation block is an encrypted set of counters that are used in accounting audits. Let be an additive homomorphic encryption of message Q using public key ; that is, , where is the private key and ⊕ is modular addition.
We perform multiple simultaneous homomorphic additions using a single ciphertext by partitioning the plaintext message Q into p elements ; that is, , where is the number of bits in D. Hence,
where the values of through are obtained by accessing the relevant “partition” of the result. Similarly, decryption of the above ciphertext gives the right-hand side of Eq. (1), which can then be deconstructed into the fixed size partitions, revealing the sums .
Importantly, Eq. (1) holds only if no summation overflows into the next higher ordered partition. In our implementation, we use the additive Paillier homomorphic encryption scheme [32] with a 1024-bit or 2048-bit modulus (i.e., 1024 and 2048-bit plaintexts). As described in Section 6.2, we partition this plaintext in a manner that allows us to store approximately 10 million entries before overflow can occur.
Given the above construction, we define the aggregation block of wiretap event i () as:
where is a large nonce and , , , and are 1Iff wiretap event i respectively corresponds to a new pen/trap wiretap, a new content wiretap, an expiring pen/trap wiretap, or an expiring content wiretap. Otherwise, the value of the counter is 0. When , we define to be 0.
Conceptually, the , , , and counters allow an accountant to determine the number of new and expiring wiretap events within a specified date range. (Recall that the Log performs the additions over the ciphertexts and returns the result to the accountant.) The inclusion of the nonces and the 1 constants enable the accountant to perform Completeness checks between two timestamps and , where the two nonces and provide an efficient arithmetic check to ensure that no intermediate events were omitted by a malicious log; this is explained in greater detail in Section 5.
Special message types
The Wiretap Authority authorizes a wiretap for a given validity period . At the start of this period, the Encryptor generates a wiretap event where the content is the string “start”. Similarly, at the end of the period, the Encryptor produces an event with the contents “stop”. Both events are transmitted using the standard message format. (Note that in the former case, either or will be 1, and in the latter case, either or will be 1.)
Heartbeat messages
The Encryptor periodically transmits a special heartbeat message for each wiretap. Injected according to a Poisson process, the heartbeats obscure the timing between consecutive events in a wiretap, and hence aggravate the Log’s ability to link (encrypted) events as belonging to the same wiretap. Additionally, the heartbeat message bounds the Log’s ability to omit entries for court and accounting audits. A heartbeat message for a wiretap w is of the form , where the , , and counters in are all 0. Each heartbeat message uses a different wiretap’s record key (r), selected in a round-robin fashion.
Audits
Our audit protocol serves three goals: to retrieve wiretap information from storage, to calculate aggregate statistics over the stored information, and to verify the authenticity, integrity, and accuracy of the results obtained from the Log. Below, we describe the audit protocols for achieving the first two goals. We defer a security analysis of the audit protocols to Section 5.
Court audits
A court audit retrieves all records for a specific wiretap from the Log. To perform a court audit, the court auditor sends the Log a request for all records between timestamps and :
A correct Log then returns all records where and is the timestamp belonging to :
Given messages , the court auditor attempts to decrypt each using the wiretap key r. Messages whose signature verification fails are ignored. Messages that cannot be decrypted (as indicated by a failure in matching the cryptographic checksum) are assumed to belong to a different wiretap (either as legitimate messages or inserted noise) and are discarded. The remaining records belong to the wiretap of interest, and gaps in sequence numbers () indicate missed messages. We note that this scheme establishes the identity message creator (an Encryptor), but not of the individual wiretap order to which the message belongs. Because the Encryptor is a trusted component, a wiretap record is sufficiently authenticated after the Encryptor signature is verified, which means that from message decryption failure we can infer that a message belongs to another wiretap order.
Accounting audits
An accounting audit should reveal the number of new and expiring wiretaps that occurred over a specified time period. To conduct an audit, the accountant transmits a request to the Log:
The Log will then determine the wiretap event indices a and z () such the times corresponding to messages and (i.e., and ) are the respective minimum and maximum times bound by .
To calculate the statistics of interest, the Log computes . From the definition of and Eq. (1), we have
The Log then returns the response:
The accountant can then decrypt to obtain the total number of new pen/trap and content wiretaps as well as the number of expiring pen/trap and content wiretaps in . Although the size of may be large due to the homomorphic additions, we note this cost is ephemeral – the Log does not store and communication costs only occur during the (infrequent) audits.
Security analysis
Given the importance of wiretap information to the evidence and investigative intelligence gathering processes, we argue that there is a significant need to accurately assess the integrity and completeness of the collected information. In this section, we describe the trustworthiness of our accountable wiretapping infrastructure in the presence of adversaries who wish to either thwart the reliable collection of wiretap data, or conduct unauthorized interception.
Detecting target-initiated DoS attacks
In the standard CALEA wiretap architecture, the target of the wiretap may cause LAESP messages to be lost in transit to the LEA by generating a flood of signaling information. Because each signal must be translated into a LAESP message, the under-provisioned connection between the DF and the LEA drops packets [44]. Since LAESP messages do not include sequence numbers [46], their loss may be undetected.
Our architecture supports the detection of lost LAESP messages through redundant storage and sequence numbering. During a court audit, wiretap records stored in the Log may be reconciled with transcripts maintained by the LEAs to detect missed LAESP messages. LEAs can fill-in the missing pieces of their wiretap transcripts using data stored at the Log. (Recall that since Log messages are signed by the trusted Encryptor, such records are guaranteed to be authentic.)
Although the connection between the Encryptor and the Log should be adequately provisioned, message loss may of course still occur. However, the use of sequence numbers enables the trivial detection and count of lost messages, achieving our Completeness goal.
Detecting unauthorized wiretaps
Our architecture detects the presence of certain unauthorized wiretaps. Notably, our solution does not protect against adversaries who can bypass the Encryptor. For example, a rogue employee of the service provider who can wiretap at various points throughout the telephone network can likely avoid detection. To mitigate such attacks, a more general data leakage prevention solution is required. In this paper, however, our focus is on reliable wiretap audits, and we briefly note that we can detect unauthorized wiretaps in the cases in which the intercepted data flows through an Encryptor. Such cases may occur, for instance, if an attacker is able to compromise a DF, but physically secured links require all outgoing communication from the DF to flow through the Encryptor.
Assuming that the unauthorized wiretap’s data are relayed through the Encryptor, then the wiretap’s presence will be revealed during accounting audits. That is, the accounting records will not reconcile with those of the Wiretap Authority, indicating the presence of the illegal wiretap. The Reporting property of our wiretap architecture allows an accountant to “hone in” on the time at which the illegal wiretap was provisioned; i.e., by conducting a binary search using multiple queries.
Protecting against a malicious Log
A Log is an outsourced storage provider that receives wiretap information from potentially many DFs. Given the sensitivity of wiretap data, the Log should not be trusted to have access to either individual wiretap records, nor should it be able to reliably discern coarse-grain data about past or ongoing wiretaps.
Confidentiality and privacy
The confidentiality of wiretap records is protected through the straightforward use of encryption: The Log does not have access to any private keys, and cannot decrypt wiretap events or aggregation blocks.
The Log knows the time that each incoming message arrives, and can use this information to reason about the number of wiretaps and the potential association between any two encrypted wiretap events (for instance, that they belong to the same wiretap). However, heartbeat messages, which are inserted according to a random Poisson process, significantly hinder the Log’s ability to perform timing analysis. The level of privacy provided by heartbeat messages is parameterizable based on the λ value of the Poisson process; however, finding an optimal λ is a deployment-specific challenge, and should be made with consideration with the expected event rate as well as security and performance constraints. However, as we show in Section 6, our accountable wiretapping architecture is highly scalable, and can easily handle a high rate of heartbeat messages, further diminishing the Log’s ability to infer linkage between encrypted events.
Court audits
In a court audit, the court auditor verifies the Integrity, Completeness and Date Compliance of the records returned by the Log. Integrity is guaranteed through the use of digital signatures.
The court auditor verifies Completeness by searching for gaps in the wiretap records’ sequence numbers (). If the sequence numbers contains gaps, then the returned results are clearly incomplete. In the case that there are no gaps in the sequence numbers, is a start message, and is a stop message, then the returned records must be complete, since the start and stop messages “bookend” the wiretap, and the authenticity of all messages are verified via the Encryptor’s digital signature. However, in all other cases, a corrupt Log may omit records at the beginning or end of the queried time interval. Hence, sequence numbers by themselves are not sufficient to verify Completeness.
The use of heartbeat messages serves to detect such omissions. Let be the non-discarded (non-heartbeat) messages returned by the Log, sorted in increasing order by the messages’ timestamps (). Additionally, let be the time interval specified by the court auditor, and and be the timestamps associated with and , respectively. Finally, let λ be the mean number of heartbeat messages per minute produced by the Poisson process for the wiretap of interest. From the definition of a Poisson process, it follows that the probability that there is at least one heartbeat message between and is , and for the time between and . Thus, the Log’s ability to omit records is constrained by λ. In summary, the court auditor can detect gaps by searching for noncontiguous sequence numbers, and can conclude with measurable confidence whether records were omitted at the endpoints by noting the presence or absence of heartbeats.
Finally, given the Completeness property, the court auditor can verify Date Compliance by issuing queries over various time intervals (in particular, ) and reconciling the results with the wiretap creation and expiration dates specified by the Wiretap Authority.
Accounting audits
Following the notation of Section 4.3, let and be the records returned by the Log in an accounting audit. Additionally, let be the purported summation of the aggregation blocks returned by the Log. (Hence, if the Log is honest and has captured all messages from Encryptor, then .) In an accounting audit, the Log must prove to the accountant that .
The authenticity and integrity of and can be easily checked by verifying their accompanying digital signatures. Using the argument described above, the use of the heartbeat message “bounds” omissions, and hence the ability of the Log to omit many records before (resp. after) (resp. ) is limited.
We define to be the second decrypted partition of (the first nonce partition), and similarly, set to be the third decrypted partition of (the second nonce partition). If , then (by the definition of our protocol), and similarly, (also by definition). Consequently, .
The accountant can compute (from ) and (from messages and that are also included in the Log’s response and whose digital signatures have previously been verified). If the Log is honest and has captured all messages between and , then .
An incorrect Log or a Log that has missed messages sent by the Encryptor can return a false result (i.e., ). However, since the accountant knows and (from messages and ), then to avoid detection, the Log must return a such that . The Log however does not have knowledge of or or (recall that the values are homomorphically encrypted and the Log does not possess the decryption key).
The incorrect Log may return a valid summation over an arbitrary subset of recorded messages – while not adhering to the time interval . (In all other cases, the dispersion property of the cryptosystem ensures that the decryption of appear random, since the Log does not have the encryption key. Thus, the probability that decrypts to the value of is negligible.) Since each nonce is chosen uniformly at random from a large space, the probability that the summations of random (and unknown) nonces and have the property is also negligible.
Aggregate block forgery
In the accounting audit protocol as described thus far, a malicious Log with public aggregation key and knowledge of aggregate block internal structure could produce false results by encrypting and aggregating additional records. If the Log introduces a forged record where , the injected record will not impact the final value , and thus the act would go undetected. Our solution to this problem is as follows. In the Paillier scheme, the public key is comprised of , where n is the product of two large prime numbers and g is a random integer . A message m’s encryption is given by . The homomorphic addition of two encrypted messages and is obtained by taking . Critically, the full public key is needed for encryption, but only the component n is required for homomorphic addition. We prevent aggregate forgery by sharing the full public key with the Encryptor, but only the component n with the Log. Because g is a random integer , we believe that the Log cannot recover g given knowledge of m. Likewise, the Log cannot recover g from a ciphertext ; among other reasons, g’s relation to the ciphertext is masked by the introduction of the random noise r.
In designing the accounting audit protocol, we considered many methods of secretly conveying wiretap statistics to the accountant, including those that did not rely on a costly homomorphic addition step and were thus more efficient. The simplest example of this would be to replace our aggregate block with a block that contained the total active wiretap statistics for a given Encryptor. To audit, the accountant could then request the two records associated with and , decrypt the blocks, and take the difference of the counters in order to obtain the statistics for that time range. Because the Log is only responsible for storage and retrieval in this scenario, it would not require any knowledge of the accountant’s public key , thus fully mitigating the threat of aggregate forgery. Unfortunately, this design violates the constraint that wiretap components in a central office should maintain minimal state [9,10]; as mentioned in Section 3, maintaining logs at a central office increases the risk that a rogue technician could enumerate past and present wiretaps. In order to minimize both the statefullness of the Encryptor and the work required by the accountant, we adopted a scheme that allowed the Log to perform aggregation through additive homomorphism.
Operational aspects
A limitation of our architecture is that it may be difficult to determine the cause(s) of a missed event. In particular, a missed message may be due to network loss, equipment failure, or the purposeful omission of a wiretap record. Court audits can reveal the scope of the omissions, which in turn may provide useful insights for statistical analysis (for example, to gauge the reliability of the network). However, in a lossy network, it is impossible to differentiate between messages that fail to reach their intended receivers due to network loss and those that are purposefully deleted in transit. Analyzing the network to detect potential causes of network loss (e.g., underprovisioning) and more closely scrutinizing the maintainer of the Log are manual processes that will need to be undertaken by the courts. We note, however, that the courts currently lack any ability to detect gaps, regardless of their causes. This was publicly highlighted in the trial of ex-Governor Rod Blagojevich, in which the defense argued that intercepted audio recordings were not admissible as evidence due to inconsistent and improper gaps [45]. The ability to detect missed events is a significant advancement, as it enables the court to assert with very high confidence whether or not a wiretap transcript is complete.
Evaluation
In this section, we describe our implementation of the Encryptor device and demonstrate its performance under realistic operating configurations and workloads.
Implementation
Given the lack of public information regarding existing CALEA wiretap implementations and the difficulty of procuring them, we chose to integrate our system with an Asterisk softswitch. Asterisk is an open source telephony program capable of bridging calls between the standard telephone network (PSTN) and voice-over-IP (VoIP) networks, including proprietary services such as Skype. Asterisk is capable of scripting telephony-related events, and in addition to a native scripting language, it allows event flows to be passed off to other scripts and processes. One such service is the FastAGI server, which is generally used to allow a single switch to accommodate additional load by outsourcing the call handling responsibilities to additional machines. We run our FastAGI server locally to mark the barrier between a Switch (where the Delivery Function is implemented) and the Encryptor. We implemented the Encryptor as a Java process that checks calls against a list of wiretap orders provided by an Authority. Figure 3 provides an overview of our implementation, showing the flow of collected call data from the call handling script processed by Asterisk to the Encryptor and discrete events entered into the Log, which can be accessed by auditors.
Our proof-of-concept Encryptor implementation. Within the Telco facilities, the Asterisk softswitch handles call events and forwards them to the to the Encryptor, which communicates securely with a remote audit log. (Colors are visible in the online version of the article; https://dx-doi-org.web.bisu.edu.cn/10.3233/JCS-140515.)
Wiretap event generation
All incoming Asterisk calls pass through the control of the Encryptor, which examines the call metadata to see if either communicant is subject to an Authority-issued wiretap. If this is the case, it begins to send encrypted call records to a remote Log. Each record contains the message that includes timestamp , encrypted call data , SHA1 checksum , and aggregation block ; it also includes the signature .
The aggregation block is encrypted using the Paillier public-key cryptosystem [32]. Paillier possesses the additive homomorphic property that , which we use to perform ciphertext addition in our accounting audit. The Paillier keys are generated to support a 1024-bit modulus and prime certainty. This creates a field of 308 digits with which to encode aggregate information.
To protect the switch from traffic analysis, the Encryptor creates a stream of cover traffic events. These events are generated according to a Poisson distribution using a secure PRNG. The frequency of the cover traffic pattern is scaled such that legitimate events are effectively obscured. Once encrypted, these events are seemingly identical to legitimate wiretap records. Because all records are signed with the private authenticity key , the Log cannot distinguish between cover and legitimate events upon their arrival. This helps obfuscate the timing information that would otherwise leak information to a dishonest maintainer. Additionally, the cover traffic events serve as our heartbeat messages to the Log.
Auditing
Our test implementation supports the two forms of audits described in Section 4.3. For court audits, a court auditor is able to issue a request for all records in the interval . The Log returns these encrypted events to the auditor. The auditor can then attempt to decrypt the returned records using its known record keys (r). Since an auditor may have access to only a subset of keys r, the (in)ability to decrypt serves as an avenue for enforcing finer-grained access control on log events. While full audits would require the attempted decryption of all events for record keys r, this is an offline and infrequent cost that can be parallelized across many cores.
For the accounting audit, the accountant issues a set of three commands. The first request is that the aggregate blocks of records be summed. The next two requests are for the records and . The auditor can then audit the Log for the given range (as described in Section 4.3) with guaranteed correctness up to the most recent heartbeat record.
Performance
In order to evaluate the throughput of our implementation, we first performed microbenchmarking tests on the different steps of creating an individual event. These tests were performed on an Intel Xeon 2.67 GHz quadcore processor; the machine had 8 GB memory and was running Linux 2.6.35. We microbenchmarked the following steps: call data hashing, aggregate block encryption (using the Paillier public-key cryptosystem), symmetric encryption of actual call data (AES used in CBC mode), signing (1024-bit DSA signatures), and transmission over an open TCP socket, with the benchmarks executed within a single-threaded process. The results of these benchmarks are displayed in Table 2.
Microbenchmarks of call record event generation with aggregate blocks using 1024 and 2048 bit moduli
Operation
1024 bit agg. block
2048 bit agg. block
Hash call data
10.57 µs
8.13 µs
Encrypt aggregate block
31,676 µs
199,310 µs
Encrypt call data
10.17 µs
9.1 µs
Sign call record
1193 µs
1073 µs
Transmission
1.8 µs
0.57 µs
Total process
32,756 µs
200,700 µs
Note: Averages and 95% confidence intervals, shown in brackets, are based on 1000 runs.
Performance degrades as the size of the aggregate block increases. Because of the overhead of encryption with the additive homomorphic property, this parameter has a significant impact on the Encryptor’s throughput. Using a 1024-bit modulus, the aggregate block encryption step represents 96.4% of the cost of record generation. Event signing consumes 3.5% of generation, and the remaining steps (record initialization, symmetric encryption, transmission) contribute less than 1%. As benchmarked, our 1024-bit Encryptor implementation can generate 30.53 events per second.
For our proof-of-concept implementation, each record contains two 64-bit nonce sequence numbers which serve as unique identifiers for the record and its predecessor. Setting a large nonce size can all but eliminate the possibility of predicting the sequence number. The aggregate block size also imposes an upper bound on the maximum size of the log. Each field in the aggregate block can only accommodate the addition of a fixed number of events before the sum bleeds into the next field of the block. Prior to this occurring, the log must be rotated. In our implementation, we designed the 1024 bit aggregate block to accommodate events before rotation was required.
At the remote Log, events may be entered into it at roughly 39,000 events per second. The system throughput is therefore entirely dependent on the speed of the Encryptor. In a realistic scenario, many delivery functions at different central offices are sending traffic to a single location. Even with our unoptimized implementation, it is clear that our Log is prepared to accommodate this one-to-many relationship.
Having determined our system throughput, we sought to test our implementation in real world conditions. To do this, we obtained an anonymized profile of all outgoing and incoming call data from a major university for a 24-hour period. No activity of any individual was exposed. The profile of this traffic is pictured in Fig. 4. In our experiment, we initiated a SIP telephone call and generated a Call Start wiretap event for every call for the busiest call windows of the day. As the peak call count per 10 minute window was only 571 calls, our Encryptor implementation was able to easily handle this traffic. With similar ease, we could have logged Call End wiretap events along with other assorted CALEA event types. Over the course of the simulation, our Encryptor operated at less than 3.2% of its maximum throughput.
Profile of traffic of a major university from April 4th, 2011. Call count is grouped by ten minute increments. (Colors are visible in the online version of the article; https://dx-doi-org.web.bisu.edu.cn/10.3233/JCS-140515.)
These results can also be extrapolated to national telephony traffic. In 2003, AT&T reported that it handled 3472 calls per second on average [17]. By our benchmark numbers using the 1024-bit aggregate block, we could generate Call Start events for 0.87% of this traffic. Our actual, Asterisk-attached implementation is already multithreaded, so it is not unreasonable to imagine that we would be able to log wiretap events for 10% of national call traffic on a single multicore machine. We believe that these numbers far exceed the actual number of wiretap events (based on the evidence below), demonstrating that our system contains significant capacity to record attacks such as those presented by Sherr et al. [44].
Yet another method of evaluating our implementation is to compare it to published wiretap statistics. In 2008, there were 20,899 pen register orders and 386 full content intercept orders [13]. Because our current implementation does not support content interception, we will consider only the pen registers. We requested the specific call rates of the university’s most called number (i.e., the main campus exchange), with 120 outgoing and 280 received calls in a single day. Let us assume that each wiretap target will initiate and receive this extremely high number of calls every day, for a total of 400 Call Start and Call End events. Conservatively assume that in 2008 there were 20,899 simultaneous pen registers on a given day. We would then expect roughly eight million events over the course of that day. At 30.53 events per second, our implementation can generate nearly three million events per day, and could therefore accommodate all of the 2008 pen registers using only three machines.
Discussion
Our accountable wiretapping architecture is not intended to be a panacea for providing more robust telecommunication. Auditing is inherently a reactive security mechanism, capturing incorrect behavior only after it occurs. Insiders with physical access to service providers’ equipment can exfiltrate information, and likely do so while evading our auditing infrastructure. In general, preventing unauthorized data exfiltration is a difficult and open problem – one which our techniques are not intended to solve. Rather, we present a wiretapping audit process and associated protocols that provide a first step towards an architecture that is more robust against manipulation and privacy violations. Although we do not prevent all plausible attacks against wiretap systems, we do ensure that wiretap data can be authenticated and that omissions in wiretap transcripts are detectable.
Microauditing
In previous sections we have operated under the assumption that audits occur infrequently, and that their performance costs were therefore irrelevant. As current law mandates wiretap usage be reported annually, this is not likely to be a major limitation to our proposal in regards to existing CALEA deployments [52]. However, future wiretap systems may require real time reporting features, or frequent integrity and completeness challenges to ensure correct operation. In this section, we introduce a series of optimizations to the auditing procedures described in Section 4.3 that allow for sublinear performance with respect to the size of the Log. Using a specialized Merkle hash tree construction [12] for Log storage, we present microaudit protocols that challenge Log correctness and integrity at each event insertion.
History trees
Following the event logging protocol described in Section 4.2, the Log stores transmitted ciphertexts in a history tree [12]. History trees are a form of Merkle trees [30] that can be used to authenticate static data. In such trees, data are stored at the leaves, and the interior nodes and root contain hashes that form tamper-evident summaries of the described contents. We refer to these tamper-evident summaries as commitments of the data. As the path length from root to leaf is logarithmic with respect to the size of the data, history trees support efficient random access. History trees extend Merkle trees by performing versioned computations of hashes over the Merkle tree. This gives history trees the ability to efficiently represent snapshots of the log from different points in time as distinct Merkle trees. Log snapshots can be compared in order to prove that they make consistent claims about the past.
A version 2 history with commitment . Subtrees containing no events are represented by □.
A version 6 history with commitment .
Our use of the history tree is as follows. Our Log from Section 4.2 is a binary history tree of depth d that can store up to wiretap events on the leaves. Interior nodes, , are identified by their index i and depth r and contain an aggregate description of the descendant wiretap events. Each leaf node , at depth 0, stores wiretap event . Each interior node has a left child and a right child . This numbering scheme is demonstrated in Figs 5–8. All nodes in the history tree, including the leaves, are labeled with cryptographic hashes that fix the contents of the subtree rooted at that node. For leaf nodes, the label is simply the hash of the contained wiretap event. For interior nodes, the label is the hash of the concatenation of the labels of its descendants.
Our audits leverage the history tree’s ability to efficiently reconstruct old versions of itself by ignoring newer events and recomputing the hashes of the interior nodes and the root. Consider the example depicted in Figs 5 and 6. Assuming that and are equal to and respectively, the tree in Fig. 6 can reconstruct the tree in Fig. 5. Using this method, the Log can generate an incremental proof for an auditor possessing commitments and . The Log returns a pruned tree P to the auditor that includes just enough of the full history to compute the commitments and , replacing unnecessary tree paths with stubs. The auditor uses P, shown in Fig. 7, to calculate and , thereby confirming that the tree committed by is consistent with the tree committed by .
An incremental proof P between a version 2 and a version 6 commitment. Hashes for the circled nodes are included in the proof. Other hashes can be derived from their children. The circled nodes must be shown to be equal to the equivalent nodes in Figs 5 and 6.
An accounting audit based on the membership proof in Fig. 7. Interior node content is generated by the aggregation function that returns .
Encryptor microaudits
We next describe how the above history tree construction can be used to perform incremental proofs of commitment and historical membership proofs.
Incremental proofs of commitment
Under our previous design, auditors were able to confirm the completeness and integrity of Log records through performing a court audit for a particular wiretap order. Described in Section 4.3, this audit involved transmitting and decrypting all events between two timestamps and . As this process is costly and requires the involvement of the supervising court, it is desirable to confirm correct Log function with greater regularity.
Modified event logging commitment protocol.
Historical membership proof protocol. and bound the timespan .
Incorporating incremental proofs, we modify our event logging protocol such that the Encryptor challenges the Log after each transmission. Shown in Fig. 9, the Log acknowledges the Encryptor’s transmission of wiretap event by sending a full incremental proof of correctness between and . The proof is a pruned tree that contains a root commitment and thus establishes consistency between commitments and .
Historical membership proofs
For scenarios in which multiple Encryptors commit to the same Log, incremental proofs are not sufficient for each Encryptor to confirm that past events have not been dropped. This is because may not correspond to an event transmitted by that particular Encryptor. It is therefore necessary for Encryptors to issue periodic challenges for past commitments. To accomplish this, the Encryptor maintains limited local state for each transmitted event, recording the tuple where is a cryptographic hash of the event, is the timestamp, and is the root commitment of the incremental proof returned by the Log. Periodically, the Encryptor requests an additional membership proof between two randomly selected records, checking the Log’s reply by referencing the locally stored tuple. This procedure is shown in Fig. 10.
Accounting microaudits
With minor modification, we can extend the history tree to facilitate the accounting audit described in Section 4.3. Rather than simply using a cryptographic hash function to commit wiretap events, we create an aggregation function that returns the tuple . Here, ⊕ is the additive homomorphic operation and and are the aggregation blocks contained within and respectively.
To conduct the audit, the accountant now transmits a request to the Log:
The Log will then determine the wiretap event indices a and z () such the times corresponding to events and (i.e., and ) are the respective minimum and maximum times bound by . It will then generated the pruned tree and return it to the accountant.
In the event that , the accountant need not perform any additional work; the root of the tree will contain the result , having incrementally generated this value as events were committed. If , the accountant can generate the result by traversing the path from to the root. During traversal, the accountant replaces subtrees for the events that occurred prior to with stubs, then recalculates the result for the traversed interior nodes. Figure 8 shows the associated tree of an accounting audit for the timespan bound by events and . The work performed by the Log is identical to the incremental proof depicted in Fig. 7.
Security analysis
The accountable wiretapping infrastructure remains fundamentally unchanged by these optimizations. In this section, we revisit the security analysis of Section 5. We find that our infrastructure not only meets the same security goals, but also offers faster detection of a variety of attacks.
Detecting target-initiated DoS attacks
As discussed previously, a wiretap target may cause LAESP messages to be lost in transit to the LEA by generating a flood of signaling information. The wiretap event message structure, unchanged by our optimizations, can still trivially detect lost messages. Moreover, the absence of an incremental proof following an event transmission will alert the Encryptor to other losses of service. Under the proposed optimizations, the added transmission cost of incremental proofs should be considered when provisioning the connection from the Log to the Encryptor.
Detecting unauthorized wiretaps
Our wiretap architecture still possesses the Reporting property, and can therefore detect the presence of unauthorized wiretaps so long as they are relayed through the Encryptor. Detection occurs during the accounting audit, at which point the auditor would not be able to reconcile the Log report with those of the Wiretap Authorities. Previously, it would be necessary to perform a series of binary searches to discover the time at which the illegal wiretap was executed. Under the proposed optimizations, the accounting audit becomes an inexpensive task. As a result, a supervising authority could perform regular accounting audits in rapid succession. For example, an accountant could perform minute-by-minute audits, allowing for the detection of illegal wiretaps in real time.
Protecting against a malicious Log
Key distribution and data encryption have not changed under the proposed optimizations. The Log still does not have access to any private keys, and cannot decrypt wiretap events or aggregation blocks. In other words, the Log cannot access individual wiretap records or coarse-grain data about past or ongoing wiretaps. The Log’s ability to perform timing analysis attacks is still frustrated by the presence of noise and heartbeat messages. Moreover, the increased speed of auditing procedures allows for faster detection of malicious activity at the Log.
Auditing
In a court audit, the court auditor verifies the Integrity, Completeness and Date Compliance of the records returned by the Log. Integrity is guaranteed through the use of digital signatures. This auditing procedure has not been changed under the proposed optimizations, and therefore exhibits the same properties. Using our microaudit protocols, the Encryptor now performs real time verification of Integrity and Completeness for the subset of wiretap events that it generated. Provided that all active Encryptors are performing microaudits, the court audit need only be performed when access to unencrypted wiretap transcripts is required.
The accountant’s role in audits remains unchanged; he can perform the same procedure described in Section 5 to detect messages missed by an incorrect Log during the audit. The Log’s work during accounting audits has been partially shifted from the time of the audit to the time of event insertion; the additive homomorphic operation is performed automatically as commitments are aggregated by the history tree. At the time of the audit, the Log needs only to generate a pruned tree for the time interval . All incorrect behavior performed by the Log is detected by the work of the accountant.
One significant change under the proposed revisions is that, to facilitate microaudits, the Encryptor maintains additional state for each event transmitted. These records are used to confirm the validity of incremental proofs and to launch historical membership proofs. Although the Encryptor is a trusted component, up to now we have assumed that wiretap data should not be stored within the Central Office so as to protect from honest-but-curious Telco employees. Fortunately, such agents will not be able to learn anything about the active wiretaps from the additional required state. The Encryptor need only store the locally generated cryptographic hash of the wiretap event, its timestamp, and the root commitment returned by the Log at the time of insertion. The timestamp does not leak meaningful information due to the generation of noise and heartbeat messages.
Performance
To evaluate the performance impact of the new microauditing procedures, we repeated the trials from Section 6.2. The proposed changes effectively shift a portion of the Log workloads to insertion-time, thereby improving the Log’s response speed for audits. Additionally, the need for incremental proofs ( in size with respect to the number of stored events) following each insertion imposes considerable transmission costs. The goal of this evaluation is therefore (1) to determine if event insertion speed is still acceptable, and (2) to quantify the performance gains enjoyed by the audits.
We ran benchmarking tests on a Dell PowerEdge R610 server (two 4-core Intel Xeon E5606 processors, 12 GB RAM) running a Linux 2.6.4 kernel. Both the Log and Encryptor were running on the same server for these tests, and thus the results do not reflect network transmission delays. We selected 5 specific operations to benchmark: Membership Proof generation, Insertion Proof generation, Accounting Proof generation, Membership Proof Evaluation, and End-to-End Insertion. In contrast with the microbenchmarks discussed in Section 6.2, the performance of these operations is dependent on the size of the Log and the length of the timespan being audited. We reflected these increased costs by pre-loading the log with an increasing number of records prior to benchmarking. For the Membership Proof Generation and Accounting Proof Generation trials, a random timespan was generated such that and . The results of these trials are contained in Table 3.
Benchmarks for proof generation and evaluation using the microauditing optimizations
Operation
210 records
212 records
214 records
216 records
Gen. Mem. Proof
20.3 µs
26.3 µs
34.3 µs
44.7 µs
Gen. Inser. Proof
25.8 µs
29.1 µs
33.3 µs
39.0 µs
Gen. Acct. Proof
1276 µs
1547 µs
1831 µs
2129 µs
Eval. Mem. Proof
1912 µs
2334 µs
2749 µs
3166 µs
End-to-End Inser.
4132 µs
4990 µs
5818 µs
6633 µs
Note: Means and 95% confidence intervals are the result of repeatedly querying the Log for proofs over randomly selected time intervals.
We next attempted to capture representative benchmarks using the Encryptor architecture without the proposed optimizations. As the new audits offer functionality that was not available in our previous evaluation, we created benchmarked routines that would offer similar assurances to our new proofs. For the Membership Proof, this required requesting every record in timespan from the Log and iteratively checking the associated signatures. For the Accounting Proof, the Log performed a linear pass through the data store and performed the additively homomorphic operation on each associated aggregate block. These routines are an implementation of the Court and Accounting Audits from Section 4.3. We represented the end-to-end insertion time of the old architecture by measuring the time required to insert a single record into the Log. The results of these trials are contained in Table 4. Note that the benchmarks for the membership and accounting proof generation are in milliseconds.
Benchmarks for the operations required to reach equivalent assurances without our microauditing optimizations
Operation
210 records
212 records
214 records
216 records
Court Audit
546 ms
2182 ms
8719 ms
34,853 ms
Acct. Audit
35 ms
143 ms
574 ms
2306 ms
End-to-End Inser.
30.5 µs
32.83 µs
35.8 µs
37.3 µs
Note: Means and 95% confidence intervals are the result of repeatedly querying the Log for proofs over randomly selected time intervals.
Contrasting Tables 3 and 4, we see that the time required to insert a record has increased by 2 orders of magnitude. For a Log with 216 records already included, the number of records that can be inserted is just 150 per second, down from 32,154 records per second under the old architecture. However, reporting speed has improved dramatically under the microauditing optimizations. Court Audits (Membership Proofs) on a 216Log can be issued and evaluated at rate of 312 per second. Court Audits under the architecture in Table 4 require 55 seconds to execute. This is a speedup of 99.9%. Accounting Audit performance also increased by 99.8%, improving to 190 requests per second from 0.3 requests per second.
To establish with finality that the microaudit-enabled infrastructure is practical in real world conditions, we repeated our trial in which anonymized trace data for an entire university was played through our system. This call data profile is described in greater detail in Section 6.2. To simulate a more realistic operating environment, the Log was preloaded with 216 call records. To better demonstrate the new features of our auditing system, during the trial we had an additional host execute accounting audits to the Log once every 15 seconds. In an actual wiretap environment, this accountant auditing schedule would provide fine-grained detection of illegal wiretap orders. The microaudits, in turn, provided real time verification of the Integrity and Completeness of the wiretap transcript. Our deployment was once again able to handle the entirety of the trace data. Based on our event generation rate of 300 per minute, record insertion rate of 150 per second, and accounting audit response rate of 190 per second, we conservatively estimate that the server was operating at just 19.77% of its maximum capacity during this trial. We note that, under our architecture, the same Integrity, Completeness and Reporting assurances would not have been possible given the resources available in our deployment.
Related work
Telephony systems and their users have long been subject to attack. The majority of such networks remain susceptible to eavesdropping attacks, due to traffic being unencrypted in the provider network cores [1] or protected by weak cryptographic algorithms over the air [2,4,5,19,24,34]. Even the contents of VoIP traffic protected by strong cryptographic algorithms can be exposed by comparing packet size and interarrival times to language constructs [55,58,59]. Instances of these networks have also proven susceptible to a range of other attacks including the exploitation of in-band signaling [37], fraudulent billing [36] and overload [47–50].
Legal interception laws mandate that telephony providers must provide law enforcement access to certain call content and metadata. In the United States, these laws are codified in Title III of the Federal Wiretap Act [52] and technically specified in documents such as the Communications Assistance for Law Enforcement (CALEA) Act [11,15,16]. While undetectable by the party or parties being monitored, wiretap systems are vulnerable to a range of attacks. Sherr et al. [43] demonstrated the ability to prevent call audio from being recorded by injecting in-band signaling tones into a conversation. Moreover, this work also demonstrated the ability to confuse dialed-digits logs, making the actual endpoint of a call difficult to discern for the eavesdropper. Follow-on work by these same authors [44] also demonstrated the ability to overload wiretapping-enabled switches, causing potentially critical data to be lost before an action could be logged. Such attacks are the direct inspiration for this work. The first defensive proposal in the academic literature sought to address these issues called for a bolt-on mechanism (the Encryptor) for Delivery Functions that securely transmitted wiretap events to an audit log [3]. The wiretap records could later be auditing by authenticated parties to ensure CALEA compliance or detect tampering. In Section 7, we propose new protocols that enable real time assurance of audit goals as wiretap events are recorded.
Another area of study seeks to address the vulnerabilities and privacy implications of lawful access through bypassing the intercept mechanisms in telephony provider networks. Wicker calls for a PKI overlay for phone networks that prevents the contextual information of individual users from being intercepted [56]. Whisper System’s RedPhone enables identity-based, end-to-end call encryption [29], thus preventing full intercept of call data in the provider network. For location-based services, there have been a variety of proposals to enable support for anonymity-preserving techniques through modifications to handsets and networks [23], or the introduction of trusted third parties [18,20,57]. In contrast, our system assuages the concerns of both law enforcement and privacy advocates by increasing the reporting capability of existing CALEA deployments.
Reliable and tamper-evident logging are critical components in a range of other systems. A number of non-cryptographic schemes rely on the “write-once” nature of their associated storage medium (e.g., PROMs) [31,33,61]. While effective at preventing overwriting, such records are difficult to audit remotely. Others have instead suggested software-based solutions relying on a variety of schemes including forward-secure signature [22,26,27,40,41,60], distributed timestamping [8,21,28,38] and Bloom Filters [42]. We make use of history trees in this work, which are a Merkle tree construction. History trees exhibit tamper-evidence by constructing and comparing historic versioned snapshots in order to ensure that they make consistent claims about the past [12]. While these schemes provide strong guarantees, they are not sufficient in our application because they typically assume that the event generator and the auditor are the same party. Moreover, these techniques do not support secure aggregation of records over user-specified time periods. Because of the increased interest in third party collection and storage of wiretap records [54], a more robust solution is required.
Conclusion
While legal wiretaps can be a central part of a legal investigation, it is important to provide oversight to help limit abuse and ensure compliance. We have proposed the first distributed auditing system for existing CALEA-compliant wiretaps. In our system, Encryptors are added to each CALEA device, and send encrypted audit records to a Log. The Log is trusted only to store encrypted records, which it can provide in a court audit, and to compute homomorphically-encrypted audit statistics, which it can deliver during an accounting audit. This allows a court to examine all records for a particular wiretap as needed, and for inexpensive periodic accounting over all wiretaps by other judicial authorities. The Log is unable to determine wiretap contents nor even what wiretaps exist, and any log alterations are easily detected.
We have shown that our system is resistant to target-initiated DoS attacks, can detect illicit wiretaps by employees of the phone company or wiretaps that exceed their legal lifetime, and will detect a dishonest Log that attempts to alter wiretap records. Our implementation results demonstrate that the system will easily scale to a level sufficient to monitor all known U.S. wiretaps on three commodity machines.
Footnotes
Acknowledgments
We thank the anonymous reviewers for their comments and suggestions. This work is partially supported by NSF Awards CNS-0916047, CNS-1064986, CNS-1118046, CNS-1204347, CNS-1223825, CNS-1117943, CNS-0964566, and CAREERs CNS-0952959, CNS-1149832 and CNS-1254198. The views expressed are those of the authors and do not reflect the official policy or position of the National Science Foundation or the U.S. Government.
References
1.
3rd Generation Partnership Project, Technical Specification Group Services and System Aspects; 3G Security; Network Domain Security; MAP application layer security, Technical Report 3GPP TS 33.200 v7.0.0.
2.
E.Barkhan, E.Biham and N.Keller, Instant ciphertext-only cryptanalysis of GSM encrypted communication, in: Proceedings of the Annual International Cryptology Conference (CRYPTO), 2003.
3.
A.Bates, K.Butler, M.Sherr, C.Shields, P.Traynor and D.Wallach, Accountable wiretapping – or – I know they can hear you now, in: Network and Distributed System Security Symposium (NDSS), 2012.
4.
E.Biham and O.Dunkelman, Cryptanalysis of the A5/1 GSM stream cipher, in: Proceedings of INDOCRYPT, 2000.
5.
A.Biryukov, A.Shamir and D.Wagner, Real time cryptanalysis of A5/1 on a PC, in: Proceedings of the Fast Software Encryption Workshop, 2000.
6.
M.Blaze and S.M.Bellovin,
Inside RISKS: Tapping, tapping on my network door, Communications of the ACM43(10) (2000), 136.
7.
British Parliament, Regulation of Investigatory Powers Act 2000: Part IV: Scrutiny etc. of investigatory powers and of the functions of the intelligence services, July 2000.
8.
A.Buldas, P.Laud, H.Lipmaa and J.Willemson, Time-stamping with binary linking schemes, in: Proceedings of CRYPTO, 1998.
9.
Cisco Systems, Inc., Cisco Voice Switch Services Configuration Guide for MGX Switches and Media Gateways, Release 5.5.10, June 2009.
Communications Assistance for Law Enforcement Act, Pub. L. No. 103-414, 108 Stat. 4279, 1994 (codified as amended in sections of 18 U.S.C. and 47 U.S.C. Sections 229, 1001–1010, 1021).
12.
S.A.Crosby and D.S.Wallach, Efficient data structures for tamper-evident logging, in: USENIX Security Symposium (USENIX), 2009.
13.
Director of the Administrative Office of the United States Courts, Report of the Director of the Administrative Office of the United States Courts on Applications for Orders Authorizing or Approving the Interception of Wire, Oral, or Electronic Communications, April 2009, Covers 2008.
14.
Director of the Administrative Office of the United States Courts, Report of the Director of the Administrative Office of the United States Courts on Applications for Orders Authorizing or Approving the Interception of Wire, Oral, or Electronic Communications, June 2011, Covers 2010.
15.
Federal Communications Commission, Communications Assistance for Law Enforcement Act, Third Report and Order CC Docket No. 97-213, 1999.
16.
Federal Communications Commission, Communications Assistance for Law Enforcement Act, Order on Remand, CC Docket No. 97-213, 2002.
17.
K.Fisher and R.E.Gruber, PADS: Processing Arbitrary Data Streams, in: Proceedings of the Workshop on Management and Processing of Data Streams (DIMACS), 2003.
18.
G.Ghinita, P.Kalnis, A.Khoshgozaran, C.Shahabi and K.-L.Tan, Private queries in location based services: anonymizers are not necessary, in: Proceedings of the 2008 ACM SIGMOD International Conference on Management of Data, SIGMOD’08, ACM, New York, NY, USA, 2008, pp. 121–132.
19.
J.D.Golic, Cryptanalysis of alleged A5 stream cipher, in: Proceedings of EuroCrypt, 1997.
20.
M.Gruteser and D.Grunwald, Anonymous usage of location-based services through spatial and temporal cloaking, in: Proceedings of the 1st International Conference on Mobile Systems, Applications and Services, MobiSys’03, ACM, New York, NY, USA, 2003, pp. 31–42.
21.
S.Haber and W.S.Stornetta, How to timestamp a digital document, in: Proceedings of CRYPTO, 1990.
22.
J.E.Holt, Logcrypt: forward security and public verification for secure audit logs, in: Proceedings of the Australasian Workshops on Grid Computing and E-Research, 2006.
23.
A.Khoshgozaran and C.Shahabi, Blind evaluation of nearest neighbor queries using space transformation to preserve location privacy, in: Proceedings of the 10th International Conference on Advances in Spatial and Temporal Databases, SSTD’07, Springer-Verlag, Berlin, Heidelberg, 2007, pp. 239–257.
S.Landau, Surveillance or Security?: The Risks Posed by New Wiretapping Technologies, MIT Press, 2011.
26.
D.Ma, Practical forward secure sequential aggregate signatures, in: Proceedings of the 2008 ACM Symposium on Information, Computer and Communications Security, ASIACCS’08, ACM, New York, NY, USA, 2008, pp. 341–352.
27.
D.Ma and G.Tsudik,
A new approach to secure logging, Trans. Storage5(1) (2009), 2:1–2:21.
28.
P.Maniatis and M.Baker, Secure history preservation through timeline entanglement, in: Proceedings of the USENIX Security Symposium (SECURITY), 2002.
R.Merkle, A digital signature based on a conventional encryption function, in: Advances in Cryptology (CRYPTO), 2006.
31.
S.Mitra, W.W.Hsu and M.Winslett, Trustworthy keyword search for regulatory-compliant records retention, in: Proceedings of the International Conference on Very Large Data Bases (VLDB), 2006.
32.
P.Paillier, Public-key cryptosystems based on composite degree residuosity classes, in: Annual International Cryptology Conference (CRYPTO), 1999.
33.
K.Pavlou and R.T.Snodgrass, Forensic analysis of database tampering, in: Proceedings of the ACM SIGMOD International Conference on Management of Data, 2006.
34.
S.Petrovic and A.Fuster-Sabater, An improved cryptanalysis of the A5/2 algorithm for mobile communications, in: Proceedings of Communication Systems and Networks, 2002.
35.
V.Prevelakis and D.Spinellis,
The Athens affair, IEEE Spectrum44(7) (2007), 18–25.
36.
A.Ramirez, Theft through cellular ‘clone’ calls, The New York Times, April 7, 1992.
37.
R.Rosenbaum, Secrets of the Little Blue Box, Esquire Magazine, October 1971, 117–125 and 222–226.
38.
D.Sandler and D.S.Wallach, Casting votes in the auditorium, in: Proceedings of the USENIX/ACCURATE Electronic Voting Technology Workshop (EVT), 2007.
39.
C.Savage U. S, Tries to make it easier to wiretap the Internet, The New York Times, September 27, 2010.
40.
B.Schneier and J.Kelsey, Cryptographic support for secure logs on untrusted machines, in: Proceedings of 7th USENIX Security Symposium, 1998, pp. 53–62.
41.
B.Schneier and J.Kelsey,
Secure audit logs to support computer forensics, ACM Transactions on Information and System Security (TISSEC)1(3) (1999), 159–176.
42.
K.Shanmugasundaram, H.Bronnimann and N.Memon, Payload attribution via hierarchical Bloom filters, in: Proceedings of the ACM Conference on Computer and Communications Security (CCS), 2004.
43.
M.Sherr, E.Cronin, S.Clark and M.Blaze,
Signaling vulnerabilities in wiretapping systems, IEEE Security & Privacy3(6) (2005), 13–25.
44.
M.Sherr, G.Shah, E.Cronin, S.Clark and M.Blaze, Can they hear me now?: A security analysis of law enforcement wiretaps, in: ACM Conference on Computer and Communications Security (CCS), 2009.
45.
M.Tarm, Rod Blagojevich seeks to toss wiretaps, The Christian Science Monitor, February 22, 2011.
46.
Telecommunications Industry Association (TIA), Lawfully Authorized Electronic Surveillance (J-STD-025-B), 2003.
47.
P.Traynor, W.Enck, P.McDaniel and T.La Porta,
Exploiting open functionality in SMS-capable cellular networks, Journal of Computer Security16(6) (2008), 713–742.
48.
P.Traynor, W.Enck, P.McDaniel and T.La Porta,
Mitigating attacks on open functionality in SMS-capable cellular networks, IEEE/ACM Transactions on Networking (TON)17(1) (2009), 40–53.
49.
P.Traynor, M.Lin, M.Ongtang, V.Rao, T.Jaeger, T.La Porta and P.McDaniel, On cellular botnets: Measuring the impact of malicious devices on a cellular network core, in: Proceedings of the ACM Conference on Computer and Communications Security (CCS), 2009.
50.
P.Traynor, P.McDaniel and T.La Porta, On attack causality in internet-connected cellular networks, in: Proceedings of the USENIX Security Symposium (SECURITY), 2007.
51.
U.S. Justice Department, Report on the use of pen registers and trap and trace devices by the Law Enforcement Agencies/Offices of the Department of Justice for Calendar Year 2008, 2008.
52.
United States Congress, Omnibus Crime Control and Safe Streets Act of 1968: Title III, Pub. L. No. 90-351, 82 Stat. 197, USA, 1968 (codified as amended in 18 U.S.C. Sections 2510–2522).
53.
United States Congress, Pub. L. No. 106-197 amended USC §2519(2)(b), USA.
54.
Verint, STAR-GATE comprehensive service provider compliance with lawful interception and data retention mandates, October 2007, available at: http://verint.com/communications_interception/file.cfm?id=51, April 30, 2011.
55.
A.M.White, K.Snow, A.Matthews and F.Monrose, Phonotactic reconstruction of encrypted VoIP conversations: Hookt on fon-iks, in: IEEE Symposium on Security and Privacy, Oakland, 2011.
56.
S.B.Wicker,
Cellular telephony and the question of privacy, Commun. ACM54(7) (2011), 88–98.
57.
S.B.Wicker,
The loss of location privacy in the cellular age, Commun. ACM55(8) (2012), 60–68.
58.
C.Wright, L.Ballard, S.Coull, F.Monrose and G.Masson, Spot me if you can: Uncovering spoken phrases in encrypted VoIP conversations, in: Proceedings of IEEE Symposium on Security and Privacy, Oakland, 2008.
59.
C.Wright, L.Ballard, F.Monrose and G.Masson, Language identification of encrypted VoIP traffic: Alejandra y Roberto or Alice and Bob?, in: Proceedings of the USENIX Security Symposium, 2007.
60.
A.A.Yavuz, P.Ning and M.K.Reiter,
BAF and FI-BAF: Efficient and publicly verifiable cryptographic schemes for secure logging in resource-constrained systems, ACM Trans. Inf. Syst. Secur.15(2) (2012), 9:1–9:28.
61.
Q.Zhu and W.W.Hsu, Fossilized index: The Linchpin of trustworthy non-alterable electronic records, in: Proceedings of the ACM SIGMOD International Conference on Management of Data, 2005.
