Tracing

Abstract: A method is introduced for detecting intrusions at the level of privileged processes. Evidence is given that short sequences of system calls executed by running processes are a good discriminator between normal and abnormal operating characteristics of several common UNIX programs. Normal behavior is collected in two waysc Synthetically, by exercising as many normal modes of usage of a program as possible, and in a live user environment by tracing the actual execution of the program. In the former case several types of intrusive behavior were studieds in the latter case, results were analyzed for false positives.

Abstract: We present a new generic black-box traitor tracing model in which the pirate-decoder employs a self-protection technique. This mechanism is simple, easy to implement in any (software or hardware) device and is a natural way by which a pirate (an adversary) which is black-box accessible, may try to evade detection. We present a necessary combinatorial condition for black-box traitor tracing of self-protecting devices. We constructively prove that any system that fails this condition, is incapable of tracing pirate-decoders that contain keys based on a superlogarithmic number of traitor keys. We then combine the above condition with specific properties of concrete systems. We show that the Boneh-Franklin (BF) scheme as well as the Kurosawa-Desmedt scheme have no black-box tracing capability in the self-protecting model when the number of traitors is superlogarithmic, unless the ciphertext size is as large as in a trivial system, namely linear in the number of users. This partially settles in the negative the open problem of Boneh and Franklin regarding the general black-box traceability of the BF scheme: at least for the case of superlogarithmic traitors. Our negative result does not apply to the Chor-Fiat-Naor (CFN) scheme (which, in fact, allows tracing in our self-protecting model); this separates CFN black-box traceability from that of BF. We also investigate a weaker form of black-box tracing called single-query "black-box confirmation." We show that, when suspicion is modeled as a confidence weight (which biases the uniform distribution of traitors), such single-query confirmation is essentially not possible against a self-protecting pirate-decoder that contains keys based on a superlogarithmic number of traitor keys.

Abstract: Summary Background In countries with declining numbers of confirmed cases of COVID-19, lockdown measures are gradually being lifted. However, even if most physical distancing measures are continued, other public health measures will be needed to control the epidemic. Contact tracing via conventional methods or mobile app technology is central to control strategies during de-escalation of physical distancing. We aimed to identify key factors for a contact tracing strategy to be successful. Methods We evaluated the impact of timeliness and completeness in various steps of a contact tracing strategy using a stochastic mathematical model with explicit time delays between time of infection and symptom onset, and between symptom onset, diagnosis by testing, and isolation (testing delay). The model also includes tracing of close contacts (eg, household members) and casual contacts, followed by testing regardless of symptoms and isolation if testing positive, with different tracing delays and coverages. We computed effective reproduction numbers of a contact tracing strategy (RCTS) for a population with physical distancing measures and various scenarios for isolation of index cases and tracing and quarantine of their contacts. Findings For the most optimistic scenario (testing and tracing delays of 0 days and tracing coverage of 100%), and assuming that around 40% of transmissions occur before symptom onset, the model predicts that the estimated effective reproduction number of 1·2 (with physical distancing only) will be reduced to 0·8 (95% CI 0·7–0·9) by adding contact tracing. The model also shows that a similar reduction can be achieved when testing and tracing coverage is reduced to 80% (RCTS 0·8, 95% CI 0·7–1·0). A testing delay of more than 1 day requires the tracing delay to be at most 1 day or tracing coverage to be at least 80% to keep RCTS below 1. With a testing delay of 3 days or longer, even the most efficient strategy cannot reach RCTS values below 1. The effect of minimising tracing delay (eg, with app-based technology) declines with decreasing coverage of app use, but app-based tracing alone remains more effective than conventional tracing alone even with 20% coverage, reducing the reproduction number by 17·6% compared with 2·5%. The proportion of onward transmissions per index case that can be prevented depends on testing and tracing delays, and given a 0-day tracing delay, ranges from up to 79·9% with a 0-day testing delay to 41·8% with a 3-day testing delay and 4·9% with a 7-day testing delay. Interpretation In our model, minimising testing delay had the largest impact on reducing onward transmissions. Optimising testing and tracing coverage and minimising tracing delays, for instance with app-based technology, further enhanced contact tracing effectiveness, with the potential to prevent up to 80% of all transmissions. Access to testing should therefore be optimised, and mobile app technology might reduce delays in the contact tracing process and optimise contact tracing coverage. Funding ZonMw, Fundacao para a Ciencia e a Tecnologia, and EU Horizon 2020 RECOVER.

Abstract: Tracing tools are used widely to help analyze, design, and tune both hardware and software systems. This paper describes a tool called Shade which combines efficient instruction-set simulation with a flexible, extensible trace generation capability. Efficiency is achieved by dynamically compiling and caching code to simulate and trace the application program. The user may control the extent of tracing in a variety of ways; arbitrarily detailed application state information may be collected during the simulation, but tracing less translates directly into greater efficiency. Current Shade implementations run on SPARC systems and simulate the SPARC (Versions 8 and 9) and MIPS I instruction sets. This paper describes the capabilities, design, implementation, and performance of Shade, and discusses instruction set emulation in general.