Institutsseminar/2022-01-21: Unterschied zwischen den Versionen
|Zeile 2:||Zeile 2:|
|raum=Raum 348 (Gebäude 50.34)
|raum=Raum 348 (Gebäude 50.34)
Aktuelle Version vom 14. Januar 2022, 14:25 Uhr
|Datum||Fr 21. Januar 2022, 12:00 Uhr|
|Ort||Raum 348 (Gebäude 50.34)|
|Vorheriger Termin||Fr 21. Januar 2022|
|Nächster Termin||Fr 28. Januar 2022|
|Titel||Architecture Extraction for Message-Based Systems from Dynamic Analysis|
|Kurzfassung||Distributed message-based microservice systems architecture has seen considerable evolution in recent years, making them easier to extend, reuse and manage. But, the challenge lies in the fact that such software systems are constituted of components that are more and more autonomous, distributed, and are deployed with different technologies. On the one hand such systems through their flexible architecture provide a lot of advantages. On the other hand, they are more likely to be changed fast and thus make their architecture less reliable and up-to-date. Architecture reconstruction method can support to obtain the updated architecture at different phases of development life cycle for software systems. However, the existing architecture reconstruction methods do not support the extraction for message-based microservice systems. In our work we try to handle this problem by extending an existing approach of architecture model extraction of message-based microservice systems from their tracing data (source code instrumented) in a way that such systems can be supported. Through our approach, we provide a way to automatically extract performance models for message-based microservice systems through dynamic analysis. We then evaluate our approach with the comparison of extracted model with the manual model with statistical metrics such as precision, recall and F1-score in order to find out the accuracy of our extracted model.|
|Titel||Modelling and Enforcing Access Control Requirements for Smart Contracts|
|Kurzfassung||Smart contracts are software systems employing the underlying blockchain technology to handle transactions in a decentralized and immutable manner. Due to the immutability of the blockchain, smart contracts cannot be upgraded after their initial deploy. Therefore, reasoning about a contract’s security aspects needs to happen before the deployment. One common vulnerability for smart contracts is improper access control, which enables entities to modify data or employ functionality they are prohibited from accessing. Due to the nature of the blockchain, access to data, represented through state variables, can only be achieved by employing the contract’s functions. To correctly restrict access on the source code level, we improve the approach by Reiche et al. who enforce access control policies based on a model on the architectural level.
This work aims at correctly enforcing role-based access control (RBAC) policies for Solidity smart contract systems on the architectural and source code level. We extend the standard RBAC model by Sandhu, Ferraiolo, and Kuhn to also incorporate insecure information flows and authorization constraints for roles. We create a metamodel to capture the concepts necessary to describe and enforce RBAC policies on the architectural level. The policies are enforced in the source code by translating the model elements to formal specifications. For this purpose, an automatic code generator is implemented. To reason about the implemented smart contracts on the source code level, tools like solc-verify and Slither are employed and extended. Furthermore, we outline the development process resulting from the presented approach. To evaluate our approach and uncover problems and limitations, we employ a case study using the three smart contract software systems Augur, Fizzy and Palinodia. Additionally, we apply a metamodel coverage analysis to reason about the metamodel’s and the generator’s completeness. Furthermore, we provide an argumentation concerning the approach’s correct enforcement. This evaluation shows how a correct enforcement can be achieved under certain assumptions and when information flows are not considered. The presented approach can detect 100% of manually introduced violations during the case study to the underlying RBAC policies. Additionally, the metamodel is expressive enough to describe RBAC policies and contains no unnecessary elements, since approximately 90% of the created metamodel are covered by the implemented generator. We identify and describe limitations like oracles or public variables.
- Neuen Vortrag erstellen