76 research outputs found

    PriLok: Citizen-protecting distributed epidemic tracing

    Get PDF
    Contact tracing is an important instrument for national health services to fight epidemics. As part of the COVID-19 situation, many proposals have been made for scaling up contract tracing capacities with the help of smartphone applications, an important but highly critical endeavor due to the privacy risks involved in such solutions. Extending our previously expressed concern, we clearly articulate in this article, the functional and non-functional requirements that any solution has to meet, when striving to serve, not mere collections of individuals, but the whole of a nation, as required in face of such potentially dangerous epidemics. We present a critical information infrastructure, PriLock, a fully-open preliminary architecture proposal and design draft for privacy preserving contact tracing, which we believe can be constructed in a way to fulfill the former requirements. Our architecture leverages the existing regulated mobile communication infrastructure and builds upon the concept of "checks and balances", requiring a majority of independent players to agree to effect any operation on it, thus preventing abuse of the highly sensitive information that must be collected and processed for efficient contact tracing. This is enforced with a largely decentralised layout and highly resilient state-of-the-art technology, which we explain in the paper, finishing by giving a security, dependability and resilience analysis, showing how it meets the defined requirements, even while the infrastructure is under attack

    PriLok:Citizen-protecting distributed epidemic tracing

    Get PDF
    Contact tracing is an important instrument for national health services to fight epidemics. As part of the COVID-19 situation, many proposals have been made for scaling up contract tracing capacities with the help of smartphone applications, an important but highly critical endeavor due to the privacy risks involved in such solutions. Extending our previously expressed concern, we clearly articulate in this article, the functional and non-functional requirements that any solution has to meet, when striving to serve, not mere collections of individuals, but the whole of a nation, as required in face of such potentially dangerous epidemics. We present a critical information infrastructure, PriLock, a fully-open preliminary architecture proposal and design draft for privacy preserving contact tracing, which we believe can be constructed in a way to fulfill the former requirements. Our architecture leverages the existing regulated mobile communication infrastructure and builds upon the concept of "checks and balances", requiring a majority of independent players to agree to effect any operation on it, thus preventing abuse of the highly sensitive information that must be collected and processed for efficient contact tracing. This is enforced with a largely decentralised layout and highly resilient state-of-the-art technology, which we explain in the paper, finishing by giving a security, dependability and resilience analysis, showing how it meets the defined requirements, even while the infrastructure is under attack

    Behind the Last Line of Defense -- Surviving SoC Faults and Intrusions

    Get PDF
    Today, leveraging the enormous modular power, diversity and flexibility of manycore systems-on-a-chip (SoCs) requires careful orchestration of complex resources, a task left to low-level software, e.g. hypervisors. In current architectures, this software forms a single point of failure and worthwhile target for attacks: once compromised, adversaries gain access to all information and full control over the platform and the environment it controls. This paper proposes Midir, an enhanced manycore architecture, effecting a paradigm shift from SoCs to distributed SoCs. Midir changes the way platform resources are controlled, by retrofitting tile-based fault containment through well known mechanisms, while securing low-overhead quorum-based consensus on all critical operations, in particular privilege management and, thus, management of containment domains. Allowing versatile redundancy management, Midir promotes resilience for all software levels, including at low level. We explain this architecture, its associated algorithms and hardware mechanisms and show, for the example of a Byzantine fault tolerant microhypervisor, that it outperforms the highly efficient MinBFT by one order of magnitude

    Intrusion Resilience Systems for Modern Vehicles

    Full text link
    Current vehicular Intrusion Detection and Prevention Systems either incur high false-positive rates or do not capture zero-day vulnerabilities, leading to safety-critical risks. In addition, prevention is limited to few primitive options like dropping network packets or extreme options, e.g., ECU Bus-off state. To fill this gap, we introduce the concept of vehicular Intrusion Resilience Systems (IRS) that ensures the resilience of critical applications despite assumed faults or zero-day attacks, as long as threat assumptions are met. IRS enables running a vehicular application in a replicated way, i.e., as a Replicated State Machine, over several ECUs, and then requiring the replicated processes to reach a form of Byzantine agreement before changing their local state. Our study rides the mutation of modern vehicular environments, which are closing the gap between simple and resource-constrained "real-time and embedded systems", and complex and powerful "information technology" ones. It shows that current vehicle (e.g., Zonal) architectures and networks are becoming plausible for such modular fault and intrusion tolerance solutions,deemed too heavy in the past. Our evaluation on a simulated Automotive Ethernet network running two state-of-the-art agreement protocols (Damysus and Hotstuff) shows that the achieved latency and throughout are feasible for many Automotive applications

    Behind the Last Line of Defense -- Surviving SoC Faults and Intrusions

    Get PDF
    Today, leveraging the enormous modular power, diversity and flexibility of manycore systems-on-a-chip (SoCs) requires careful orchestration of complex resources, a task left to low-level software, e.g. hypervisors. In current architectures, this software forms a single point of failure and worthwhile target for attacks: once compromised, adversaries gain access to all information and full control over the platform and the environment it controls. This paper proposes Midir, an enhanced manycore architecture, effecting a paradigm shift from SoCs to distributed SoCs. Midir changes the way platform resources are controlled, by retrofitting tile-based fault containment through well known mechanisms, while securing low-overhead quorum-based consensus on all critical operations, in particular privilege management and, thus, management of containment domains. Allowing versatile redundancy management, Midir promotes resilience for all software levels, including at low level. We explain this architecture, its associated algorithms and hardware mechanisms and show, for the example of a Byzantine fault tolerant microhypervisor, that it outperforms the highly efficient MinBFT by one order of magnitude

    The KISS principle in Software-Defined Networking: a framework for secure communications

    Get PDF
    Security is an increasingly fundamental requirement in Software-Defined Networking (SDN). However, the pace of adoption of secure mechanisms has been slow, which we estimate to be a consequence of the performance overhead of traditional solutions and of the complexity of their support infrastructure. To address these challenges we propose KISS, a secure SDN control plane communications architecture that includes innovative solutions in the context of key distribution and secure channel support. Core to our contribution is the integrated device verification value (iDVV), a deterministic but indistinguishablefrom-random secret code generation protocol that allows local but synchronized generation/verification of keys at both ends of the control channel, even on a per-message basis. We show that our solution, while offering the same security properties, outperforms reference alternatives, with performance improvements up to 30% over OpenSSL, and improvement in robustness based on a code footprint one order of magnitude smaller

    Diversity in automatic cloud computing resource selection

    Get PDF
    Tese de mestrado em Informática, apresentada à Universidade de Lisboa, através da Faculdade de Ciências, 2012Obter resultados e comportamentos correctos em computação é uma preocupação de longa data. O excerto seguinte sobre o advento das máquinas de calcular foi escrito em 1834 e ilustra a importância já dada naquela época ao uso de mecanismos para tolerar e identificar erros de cálculo [24]: “A verificação mais correcta e efectiva contra erros que surgem do processo de computação ´e realizar a mesma computação em máquinas de calcular separadas e independentes; e tal verificação ´e ainda mais decisiva se os cálculos forem realizados através de métodos diferentes.” Existem dois mecanismos que surgem desta afirmação e são considerados importantes para obter computações correctas. O primeiro é a replicação, a qual consiste em calcular os resultados mais de uma vez e compará-los ou realizar uma votação no final. O segundo ´e a diversidade, a qual consiste em utilizar métodos e componentes distintos em cada computação. Actualmente, ambos integram o grupo de mecanismos para tolerância a faltas e intrusões (FIT), os quais são capazes de tolerar tanto faltas acidentais como maliciosas em sistemas computacionais. Em termos práticos, um serviço replicado pode tolerar faltas acidentais se existir pelo menos um servidor no seu grupo de réplicas que ainda seja capaz de responder aos pedidos dos clientes. O mesmo serviço replicado pode tolerar faltas maliciosas, normalmente, se a maioria das réplicas responderem correctamente ou concordarem com o resultado dos pedidos dos clientes. Caso um atacante descubra uma vulnerabilidade que possa ser explorada em um servidor, e a mesma também existir em outras réplicas, então a tolerância a faltas e intrusões do serviço pode ser comprometida. Tal problema ´e uma limitação conhecida dos mecanismos de replicação frente a vulnerabilidades comuns entre as réplicas. Aumentar a independência de vulnerabilidades ´e o principal objectivo do mecanismo de diversidade. A diversidade ´e um mecanismo que consiste em fornecer e criar diversas combinações de recursos entre os componentes de um sistema. Obtê-la automaticamente ´e um processo que pode ser decomposto em duas fases: criação e selecção. A primeira consiste em fornecer recursos diferentes o suficiente para serem considerados, combinados e selecionados na segunda fase. A obtenção automática de diversidade na fase de selecção de recursos é o nosso principal objectivo nesta dissertação. Gerir grandes quantidades de recursos computacionais ´e uma tarefa complexa que pode ser facilitada com o uso de ferramentas automáticas para alocação, utilização e monitorização. Actualmente, pensar na gestão de sistemas distribuídos em larga escala implicitamente leva a considerar ferramentas de cloud computing como uma das opções de gestão. O modelo de cloud computing, na sua definição mais simples, é um modelo de fornecimento de computação como um serviço de utilidade [20]. Porém tecnicamente, este modelo e seus agentes são fontes infinitas de recursos computacionais, administrados automaticamente e fornecidos publicamente. Neste trabalho, nós consideramos cloud computing como o cenário para atingirmos nosso objectivo principal. Considerando que o fornecedor de um serviço replicado seja cliente de um dado serviço de cloud, e que todas as réplicas do serviço são alocadas nesta mesma infraestrutura. Se uma falta, seja ela por paragem ou arbitrária, causar uma interrupção¸ ao do serviço prestado por essa cloud, então o serviço replicado pode falhar na sua totalidade, o que significa que não existe independência de vulnerabilidade entre as réplicas do serviço. Neste caso, existe um ponto único de falha, o provedor de cloud, o que leva a indicação da diversidade deste componente uma possível solução para o caso. O primeiro passo para obter diversidade de provedor é criar novas contas em outros fornecedores. O segundo passo consiste em seleccionar, para cada nova réplica do serviço, um fornecedor disponível que não esteja a ser utilizado pelas outras réplicas. Contudo, seleccionar manualmente um fornecedor de cloud para cada nova alocação pode ser inconveniente, ou até mesmo inviável, o que torna imperativo o uso de uma ferramenta automática para selecção de recursos. Nesta dissertação, nós apresentamos o DiversityAgent, uma biblioteca em Java para obtenção automática de diversidade na selecção de recursos de cloud computing. Seus clientes apenas precisam registar quais são os recursos disponíveis, que o DiversityAgent se responsabiliza por seleccionar uma combinação de recursos diferente para cada nova réplica a ser alocada e implantada. Acreditamos nesta ser a primeira biblioteca automática com tal propósito, tendo em vista conformidade, extensibilidade, escalabilidade e outros requisitos. O DiversityAgent foi projectado tendo em vista quatro requisitos funcionais, nove não funcionais e alguns padrões de projecto bastante difundidos. O fluxo do algoritmo principal de selecção de recursos é baseado em uma proposta colaborativa entre as diversidades registadas no momento de cada pedido, o qual será discutido no decorrer deste documento. Também são apresentadas a composição¸˜ao interna do DiversityAgent e os algoritmos de diversidade e controladores para cloud implementados. A biblioteca DiversityAgent ´e um software livre e de código aberto que se encontra disponibilizada no Google Project Hosting [10] sobre a licença GNU Lesser General Public License (LGPL v3.0). Esperamos que a mesma possa contribuir com muitos projectos do grupo Navigators, assim como externos em busca de solucionar os problemas ainda considerados em aberto na área de gestão de diversidade. Incentivamos o desenvolvimento de novos algoritmos e propriedades de diversidade, assim como novos drivers para mais provedores e ferramentas de cloud e esperamos poder publicar contribuições da comunidade de software livre para com esta ferramenta em futuras versões oficiais. Além disso, nós realizamos uma ampla análise de diversidade no cenário de cloud computing. Este estudo é composto por uma revisão de taxonomia e discussão sobre cada uma das classificações, onde apontamos as propriedades que actualmente são suportadas pelos fornecedores e ferramentas de cloud. Nele, apresentamos também algumas oportunidades para que os agentes de cloud computing possam contribuir ainda mais com a área de gestão de diversidade. Mais de cinquenta propriedades foram identificadas, sendo quatro relativas à diversidade de aplicação, catorze à diversidade administrativa, dez de localização geográfica, nove de software de suporte, nove de hardware e seis relativas à diversidade de segurança. Do total de cinquenta e duas propriedades, apenas oito são completamente suportadas pela versão analisada da ferramenta para cloud computing Open- Nebula e treze pelo fornecedor de cloud Amazon. Ainda em relação à Amazon, outras dezoito propriedades são parcialmente suportadas através do uso de rótulos genéricos, totalizando trinta e uma propriedades suportadas. Os provedores de cloud computing podem vir a não concordar em fornecer informações relativas a todas as propriedades definidas nesta dissertação, uma vez que existem riscos comerciais e custos extras em publicar e manter todas informações. Porém, ainda assim consideramos importante para a área de gestão de diversidade a apresentação e discussão do maior número possível de propriedades. Nós também apresentamos a integração do DiversityAgent com dois casos de uso previstos pelo projecto CloudFIT, assim como os resultados dos experimentos de desempenho e conformidade. O primeiro caso é um serviço Web sem estado e o segundo é um serviço baseado em replicação de máquinas de estado. Ambos casos utilizam técnicas de recuperação proactiva e posicionam o DiversityAgent entre o gestor de recursos dos serviços e os provedores de cloud, a fim de obter diversidade automaticamente a cada nova troca proactiva de réplicas. No fim desta dissertação, encontram-se as conclusões obtidas com este trabalho, possíveis trabalhos futuros, além de três apêndices sobre as interfaces públicas, tutoriais de utilização e personalização do DiversityAgent.Obtaining correct results and behaviour on computing is a long-standing concern. Such guarantee can be obtained through fault and intrusion tolerance mechanisms, which aim to tolerate crash and arbitrary faults. Byzantine fault tolerant replication, when combined with proactive recovery techniques can tolerate any number of arbitrary faults during entire system life time. However, common vulnerabilities shared between replicas can compromise such tolerance, rendering diversity as a complementary mechanism. Diversity is a mechanism that consists in providing and combining diverse resources to increase vulnerability independence between system components. Obtaining diversity automatically is a process that can be decomposed into two phases: creation and selection. The first phase consists in providing enough diverse resources to be considered, combined and selected in second phase. In this thesis we present the DiversityAgent, a Java library for selecting cloud resources considering multiple diversity properties. Its clients only need to register available resources, then the DiversityAgent assumes the responsibility of selecting appropriate cloud computing resource combination for each server deployment. In order to design the DiversityAgent, we review taxonomies for diversity on computer systems and analyse several diversity group properties supported by cloud providers or tools, and opportunities for cloud computing players contribute with diversity management area. This document contains a review on basic fault and intrusion tolerance mechanisms, followed by an extensive diversity analysis in cloud computing environments and by the DiversityAgent development. We also present an integration of our component with two use cases foreseen by CloudFIT project, as well as present the results of correctness and performance evaluations. At the end there are the final remarks about this work and possible future work, besides three appendices regarding DiversityAgent public interfaces, usage and customising tutorials

    Facing the Safety-Security Gap in RTES: the Challenge of Timeliness

    Get PDF
    Safety-critical real-time systems, including real-time cyber-physical and industrial control systems, need not be solely correct but also timely. Untimely (stale) results may have severe consequences that could render the control system’s behaviour hazardous to the physical world. To ensure predictability and timeliness, developers follow a rigorous process, which essentially ensures real-time properties a priori, in all but the most unlikely combinations of circumstances. However, we have seen the complexity of both real-time applications, and the environments they run on, increase. If this is matched with the also increasing sophistication of attacks mounted to RTES systems, the case for ensuring both safety and security through aprioristic predictability loses traction, and presents an opportunity, which we take in this paper, for discussing current practices of critical realtime system design. To this end, with a slant on low-level task scheduling, we first investigate the challenges and opportunities for anticipating successful attacks on real-time systems. Then, we propose ways for adapting traditional fault- and intrusiontolerant mechanisms to tolerate such hazards. We found that tasks which typically execute as analyzed under accidental faults, may exhibit fundamentally different behavior when compromised by malicious attacks, even with interference enforcement in place

    Operations with Degraded Security

    Get PDF
    Modern systems aren't designed to support some ongoing operations after their security is compromised. Using the ResiliNets model, the authors discuss five strategies for operating in a degraded security environment
    corecore