Spelling suggestions: "subject:"merkle trä"" "subject:"merkle tråd""
1 |
Keeping an Indefinitely Growing Audit Log / En kontinuerligt växande audit logAndersson, Måns January 2022 (has links)
An audit log enables us to discover malfeasance in a system and to understand a security breach after it has happened. An audit log is meant to preserve information about important events in a system in a non-repudiable manner. Naturally, the audit log is often a target for malicious actors trying to cover the traces of an attack. The most common type of attack would be to try to remove or modify entries which contain information about some events in the system that a malicious actor does not want anyone to know about. In this thesis, the state-of-the-art research on secure logging is presented together with a design for a new logging system. The new design has superior properties in terms of both security and functionality compared to the current EJBCA implementation. The design is based on a combination of two well-cited logging schemes presented in the literature. Our design is an audit log built on a Merkle tree structure which enables efficient integrity proofs, flexible auditing schemes, efficient queries and exporting capabilities. On top of the Merkle tree structue, an FssAgg (Forward secure sequential Aggregate) MAC (Message Authentication Code) is introduced which strengthens the resistance to truncation-attacks and provides more options for auditing schemes. A proof-of-concept implementation was created and performance was measured to show that the combination of the Merkle tree log and the FssAgg MAC does not significantly reduce the performance compared to the individual schemes, while offering better security. The logging system design and the proof-of-concept implementation presented in this project will serve as a starting point for PrimeKey when developing a new audit log for EJBCA. / En granskningslogg är viktig eftersom den ger oss möjligheten att upptäcka misstänkt aktivitet i ett system. Granskningsloggen ger också möjligheten att undersöka och förstå ett säkerhetsintrång efter att det har inträffat. En attackerare som komprometterar ett system har ofta granskningsloggen som mål, eftersom de ofta vill dölja sina spår. I denna rapport presenteras en litteraturstudie av nuvarande forskning på säkra loggingsystem samt en design av ett nytt loggingsystem. Det nya loggingsystemet har bättre säkerhetsegentskaper och funktionalitet jämfört med den nuvarande implementationen i EJBCA. Designen bygger på en kombination av två välciterade forskningsartiklar. Vår design är en granskningslogg baserad på en Merkle träd-struktur som möjliggör effektiva bevis av loggens integritet, flexibel granskning, effektiv sökning och exportfunktionalitet. Förutom Merkle träd-strukturen består den nya loggen även av en FssAgg (Forward secure sequential Aggregate) MAC (Message Authentication Code) som förstärker loggens motstånd mot trunkeringsattacker och möjliggör fler sätt att granska loggen. En prototypimplementation skapades och prestandamätningar genomfördes som visar att kombinationen av Merkle träd-loggen och FssAgg MAC:en inte försämrar loggens prestanda jämfört med de individuella logglösningarna, trots att starkare säkerhet uppnås. Designen av det nya loggingsystemet samt prototypimplementationen kommer att utgöra en grund för PrimeKeys arbete med att implementera en ny audit log i EJBCA.
|
2 |
Using Hash Trees for Database Schema Inconsistency DetectionSpik, Charlotta January 2019 (has links)
For this work, two algorithms have been developed to improve the performance of the inconsistency detection by using Merkle trees. The first builds a hash tree from a database schema version, and the second compares two hash trees to find where changes have occurred. The results of performance testing done on the hash tree approach compared to the current approach used by Cisco where all data in the schema is traversed, shows that the hash tree algorithm for inconsistency detection performs significantly better than the complete traversal algorithm in all cases tested, with the exception of when all nodes have changed in the tree. The factor of improvement is directly related to the number of nodes that have to be traversed for the hash tree, which in turn depends on the number of changes done between versions and the positioning in the schema of the nodes that have changed. The real-life example scenarios used for performance testing show that on average, the hash tree algorithm only needs to traverse 1,5% of the number of nodes that the complete traversal algorithm used by Cisco does, and on average gives a 200 times improvement in performance. Even in the worst real-life case used for testing, the hash tree algorithm performed five times better than the complete traversal algorithm. / I detta arbete har två algoritmer utvecklats for att förbättra prestandan på processen att hitta skillnader mellan schemana genom att använda Merkle träd. Den första bygger ett hashträd från schemaversionen, och den andra jämför två hashträd för att hitta var förändringar har skett. Resultaten från prestandautvärderingen som gjorts på hashträdalgoritmen jämfört med nuvarande algoritm som används på Cisco där all data i schemat traverseras, visar att hashträdalgoritmen presterar signifikant bättre än algoritmen som traverserar all data i alla fall som testats, förutom då alla noder har ändrats i trädet. Förbättringsfaktorn är direkt kopplad till antalet noder som behöver traverseras för hashträdalgoritmen, vilket i sin tur beror på antalet förändringar som skett mellan versionerna och positioneringen i schemat av de noder som har förändrats. De exempelscenarior som har tagits från riktiga uppdateringar som har skett för existerande scheman visar att i genomsnitt behöver hashträdalgoritmen bara traversera 1,5% av noderna som den nuvarande algoritmen som används av Cisco måste traversera, och hashträdalgoritmen ger i genomsnitt en 200 gånger prestandaförbättring. Även i det värsta fallet för dessa uppdateringar tagna från verkliga scenarier presterade hashträdalgoritmen fem gånger bättre än algoritmen som traverserar all data i schemat.
|
3 |
LF-PKI: Practical, Secure, and High-Performance Design and Implementation of a Lite Flexible PKI / LF-PKI: Praktisk, säker och Högpresterande design och Implementering av Lite Flexible PKIXu, Yongzhe January 2022 (has links)
Today’s Web Public Key Infrastructure (PKI) builds on a homogeneous trust model. All Certificate Authorities (CAs) are equally trusted once they are marked as trusted CAs on the client side. As a result, the security of the Web PKI depends on the weakest CA. Trust heterogeneity and flexibility can be introduced in today’s Web PKI to mitigate the problem. Each client could have different levels of trust in each trusted CA, according to the properties of each CA, such as the location, reputation and scale of the CA. As a result, the loss caused by the compromise of a less trusted CA will be relieved. In this work, we study Flexible-PKI (F-PKI), which is an enhancement of Web PKI, and propose Lite Flexible-PKI (LF-PKI) to address the limitations of F-PKI. LF-PKI is designed to securely and efficiently manage domain policies and enable trust heterogeneity on the client side. The domain owner can issue domain policies for their domains, and the client will have a complete view of the domain policies issued for a specific domain. Based on the collection of domain policies from LF-PKI, trust heterogeneity can be achieved on the client side. Each client will choose the domain policies based on the trust levels of the CA. On the basis of the LF-PKI design, a high-performance implementation of LF-PKI was developed, optimized, and analyzed. The optimized implementation can provide the LF-PKI services for worldwide domains on a single server with moderate hardware. / Dagens Web Public Key Infrastructure (PKI) bygger på en homogen förtroendemodell. Alla certifikatutfärdare (CA) är lika betrodda när de är markerade som betrodda certifikatutfärdare på klientsidan. Som ett resultat beror säkerheten för webb-PKI på den svagaste CA. Förtroendeheterogenitet och flexibilitet kan införas i dagens webb-PKI för att mildra problemet. Varje klient kan ha olika nivåer av förtroende för varje betrodd certifikatutfärdare, beroende på egenskaperna hos varje certifikatutfärdare, såsom certifikatutfärdarens plats, rykte och omfattning. Som ett resultat kommer förlusten som orsakats av kompromissen av en mindre pålitlig CA att avhjälpas. I detta arbete studerar vi Flexible-PKI (F-PKI), som är en förbättring av webb-PKI, och föreslår Lite Flexible-PKI (LF-PKI) för att ta itu med begränsningarna hos F-PKI. LF-PKI är utformad för att säkert och effektivt hantera domänpolicyer och möjliggöra förtroendeheterogenitet på klientsidan. Domänägaren kan utfärda domänpolicyer för sina domäner, och klienten kommer att ha en fullständig bild av domänpolicyerna som utfärdats för en specifik domän. Baserat på insamlingen av domänpolicyer från LF-PKI kan förtroendeheterogenitet uppnås på klientsidan. Varje klient kommer att välja domänpolicyer baserat på förtroendenivåerna för CA. På basis av LF-PKI-designen utvecklades, optimerades och analyserades en högpresterande implementering av LF-PKI. Den optimerade implementeringen kan tillhandahålla LF-PKI-tjänster för världsomspännande domäner på en enda server med måttlig hårdvara.
|
Page generated in 0.0483 seconds