Abstract
Since its introduction in Bitcoin, the blockchain has proven to be a versatile data structure. In its role as an immutable ledger, it has grown beyond its initial use in financial transactions to be used in recording a wide variety of other useful information.
In this paper, we explore the application of the blockchain outside of its traditional decentralized, financial domain. We show how, even with only a single “mining” node, a proof-of-work blockchain can be the cornerstone of a tamper resistant logging framework. By attaching a proof-of-work to blocks of logging messages, we make it increasingly difficult for an attacker to modify those logs even after totally compromising the system. Furthermore, we discuss various strategies an attacker might take to modify the logs without detection and show how effective those evasion techniques are against statistical analysis.
You have full access to this open access chapter, Download conference paper PDF
Similar content being viewed by others
Keywords
1 Introduction
Since its introduction, Bitcoin [23] has revolutionized the world of finance and of distributed consensus. Systems such as Paxos [18] had previously provided decentralized consensus, but these were fairly complex systems and did not guarantee availability. In contrast, Bitcoin introduces Nakamoto consensus, a probabilistic consensus that provides high availability. Since its introduction, other protocols have attempted to improve upon its design. Ethereum [30] introduced quasi-Turing complete smart contracts. Tezos [11] sought more graceful evolution of a blockchain protocol by letting clients vote on blockchain proposals and automatically upgrading to successful proposals, thus avoiding many problems with hard forks. Several protocols sought to improve on the consensus mechanism, either by modifying the proof-of-work mechanism [16, 17, 22] or by eliminating it totally [7, 12, 15, 28].
The blockchain is central to the design of BitcoinFootnote 1. With this data structure, a block is chained to the previous block by a cryptographic hash. This chain of hashes continues back to the first block in the chain, referred to as the genesis block. With this design, any change made to a block invalidates all subsequent blocks. Conflicting blocks might both be valid, but blockchain protocols resolve this by clear rules for prioritizing blocks; in the case of Bitcoin, the blockchain with the most hashing power used in its computation is the highest priority.
The blockchain data structure has traditionally been used in decentralized, distributed systems. In this paper, we show how the blockchain may be useful in a centralized system.
We create a logging framework that stores its logging messages as transactions in a local proof-of-work blockchain. If the system is later compromised by an attacker, the blockchain helps to prevent the attacker from modifying the logging messages without detection. An attacker could log fraudulent messages after the compromise. They could even modify recent log messages by rewriting the blockchain and expending the necessary computation to redo the search for valid proof-of-work solutions. However, the older the message, and the more deeply that message is buried in the blockchain, the more difficult it becomes for the attacker to tamper with the log without detection.
To evaluate our idea, we implemented our logging framework using the SpartanGold blockchain framework [4]. We produced a dataset of 30 sample blockchains in JSON format, and then experimented with various attacks.
Our results show that unsophisticated attacks where an attacker simply rebuilds the blockchain from a specific block are easily detected. A more subtle attacker would modify the block times so that each rebuilt block takes only slightly longer than would be typical for a block to be produced. Our results show that the attacker can only change the block creation times by a fairly slight amount to avoid detection.
The algorithm used to detect this type of tampering is a deep learning model trained on pairs of hash IDs and timestamp differences between the current and previous block (this approximates the time required to create the current block). We noticed that the model was not able to detect such an attack when the difference between the timestamps was comparable with the average time of the creation of a legitimate block. Precisely, the model became unreliable when the range of time between the current timestamp and the previous one was between 2 and 8 s.
Our defense gives the attacker a challenging dilemma. The more aggressively the attacker increments the block time, the more likely they are to be caught; however, if they are too cautious, an outside observer might notice the change before the blockchain can be rebuilt.
2 Background and Related Work
Many have observed the potential utility of storage on the blockchain and its value in providing a public, tamper-resistant data store. Indeed, storing data on the Bitcoin blockchain was frequent enough that Bitcoin added support for an OP_RETURN opcode to allow the storage to be done in a more efficient manner.
A few protocols have focused on using storage as part of their consensus. Permacoin [22] sought to reduce Bitcoin’s proof-of-work requirements by requiring that miners also prove that they are storing a portion of the Library of Congress; storage here is a “public good”, and is not intended to be used for storing arbitrary data. Spacemint [25] replaces the proof-of-work portion of Bitcoin with a proof-of-space system; this data is “junk” data, in the sense that it has no utility outside of the protocol.
Namecoin [24] is a fork of Bitcoin focused on storing arbitrary data, acting as a decentralized and distributed key-value store. Ali et al. introduce Blockstack [2] to serve as a decentralized public-key infrastructure (PKI); their initial model used Namecoin, though they later migrated to Bitcoin due to the greater security offered by the Bitcoin network’s stronger hashing power.
Ethereum offers storage on its blockchain, but it is expensive. Several blockchain protocols have attempted to provide storage, including Filecoin [10], Storj [27], Siacoin [29], and 0Chain [21].
Intrusion detection has been tackled with machine learning algorithms with promising results. Since 1980, when the first intrusion detection system (IDS) was proposed [3], the field experienced several evolving steps. Analytical and statistical techniques have recently been substituted by machine learning models due to their superiority in detecting attacks. In [9], deep learning is compared with traditional intrusion analysis showing how much more effective the application of machine learning is in this field. Another example is the survey in [1], where different machine learning techniques are analyzed and compared on network intrusion detection. The survey concludes that the most widely applied and best performing algorithm is deep learning.
Network Intrusion Detection Systems (NIDS) are among the most explored fields where we find the application of IDS; however, it has been applied in a vast range of areas, such as detecting compromised land vehicles and aerial drones. In [26], the authors explore attacks to automotive Controller Area Networks (CANs) applying machine learning techniques to identify the theft of a vehicle. The work in [14] utilizes machine learning and blockchain technology to evade intrusions in the piloting system of Unmanned Aerial Vechicles (UAVs). In this case, the blockchain is used to share and upgrade several machine learning models to ensure that the most updated one is being used at all times without external compromising.
Biometric evaluation is also applied to identify intrusion. The work in [13], for example, assumes that the intruder has access to real users’ gesture data and applies Convolutional Neural Networks (CNNs) to detect tampering of the data to bypass user authentication.
While many papers [6, 8, 19] have approached the conjunction of blockchain technology and machine learning, there seems to be a lack in the literature when we assume a complete compromising of the machines hosting the blockchain and, thus, no applications of machine learning to detect compromised blocks have yet been proposed to the best of our knowledge.
3 Logger Design and Implementation
Our logging framework writes messages to transactions on a local blockchain, helping to ensure the integrity of logging messages even should the system hosting the logs be compromised.
In this section, we briefly give an overview of the SpartanGold blockchain framework, review the code for our logging library, and finally discuss possible future extensions for the library.
3.1 SpartanGold Overview
SpartanGold [4] is a simplified blockchain written in JavaScript designed for experimentation and education; as such, it is an ideal tool for our experiments. Like Bitcoin, it uses the hashcash protocol [5] for proof-of-work consensus. However, there are some notable differences from Bitcoin:
-
SpartanGold uses an account-based model, similar to Ethereum, rather than Bitcoin’s unspent transaction output (UTXO) model.
-
The proof-of-work target for mining a block in SpartanGold does not adjust over time.
-
SpartanGold does not support smart contracts.
-
Transactions in SpartanGold are stored directly in the block, rather than in a Merkle tree [20].
-
A block in SpartanGold does not have a strict size limit.
Although SpartanGold does not support smart contracts, new functionality can be introduced by extending the Miner or Block classes. The homepage for SpartanGoldFootnote 2 includes several sample implementations of different blockchain protocols.
The most notable limitation of SpartanGold for our purposes is that it does not use a Merkle tree. In Bitcoin, all transactions are contained in a single hash value (the Merkle root) that is hashed during the mining process. In contrast, all transactions in SpartanGold are stored in a map; the full contents of the map are directly hashed during the mining process. As a result, if there are a large number of transactions, or even a single large transaction, the size of the block might exceed the size of the hash function’s input; when this happens, the mining power required to find a block is multiplied by the number of hashing rounds required to hash the block once.
In our performance experiments, we avoided this problem by leaving the blocks at a constant size. In a real implementation, we could resolve the issue by extending SpartanGold’s Block class to store a Merkle root of transactions rather than the transactions themselves.
3.2 Logging Framework Codebase
We adapt SpartanGold to add the functionality needed for a logging framework. In our design, every log message writes a transaction to the blockchain. Every transaction therefore must include both a logging level and the log message itself. Since the time of the log message might not correspond to the time of the block, every transaction must also include a timestamp.
Figure 1 shows the Logger class. The log levels specified as constants at the top of the file (lines 8–9) are loosely based on the log levels for Apache’s Log4J logging frameworkFootnote 3. Convenience methods at the end of the file (lines 52–70) write log messages at the corresponding levels. One exception is the Block_TIME level; our logging framework uses this level to track the time that the miner began searching for a proof for the block. Every block should have exactly one transaction with this log level.
The constructor (lines 13–16) initializes the blockchain, including setting the proof-of-work target (powLeadingZeroes). It calls the initializeBlockchain method (lines 35–46), which creates a new miner (line 33), makes the genesis block (lines 35–42)Footnote 4, and then triggers the miner to begin mining new blocks (line 45). (The FakeNet class (lines 32 and 43) uses events to simulate network traffic between clients and miners. It is not particularly useful in this case, but is required boilerplate code.)
Once the logger is initialized, the startServer method (lines 18–29) will start listening for incoming TCP/IP connections on the specified port. When a message is received (line 21), the message is converted to a string (line 22) and the logging level and the message are extracted from the string (lines 23–24). This information is then used to invoke the log method of the logger class.
Most of SpartanGold’s standard classes work well for our implementation. However, we extend SpartanGold’s Miner class to make LoggingMiner. Two changes are worthy of closer attention.
The startNewSearch method is called whenever a search for a new block proof begins. Its responsibility is to create the block of transactions and intialize the proof field so that the proof-of-work search can begin. We extend this method to add a special transaction with the timestamp of the block. The constant BLOCK_TIME_LEVEL is set to 5, matching the BLOCK_TIME constant defined in the logging class. (As we shall see in Sect. 4.2, this method also gives us a good hook to introduce a delay in block production, simulating an attack on the log.)
The code for the startNewSearch method is shown below:
![figure a](http://media.springernature.com/lw685/springer-static/image/chp%3A10.1007%2F978-3-031-24049-2_6/MediaObjects/539328_1_En_6_Figa_HTML.png)
The postLoggingTransaction method sends a transaction to the miner for inclusion in the blockchain. It calls postGenericTransaction from its parent class, which handles many of the banal details about posting the transaction. Since we do not care about coins for these transactions, the ouputs field specifying who gets paid is empty, and the fee of coins to pay the miner for including this transaction is set to 0.
The data field of a SpartanGold transaction is deliberately unspecified to allow for greater ease in expanding the code. In our case, we include the level of the log, the message, and the timestamp.
The method is shown below:
![figure b](http://media.springernature.com/lw685/springer-static/image/chp%3A10.1007%2F978-3-031-24049-2_6/MediaObjects/539328_1_En_6_Figb_HTML.png)
3.3 Extensions
Our design uses a blockchain locally for storing messages. Given the blockchain’s utility in decentralized systems, incorporating multiple servers is a natural extension.
Instead of sending transactions to a single miner, it would be straightforward to send the transactions to a network of machines, allowing them to come to consensus through the usual mining process. This approach might be useful in a company with a large network of machines.
Alternately, a smaller company might write their logs to an external blockchain. This approach might raise concerns if the logs contain any confidential data. Additionally, the cost of blockchain storage might be prohibitive.
Instead, if the logger periodically writes the hash of the latest block to the external blockchain, then we can detect any tampering of the local log file. However, it would not be possible to recreate the original logging data with this approach.
4 Experimental Results
To validate our design, we have generated a series of blockchains to serve as our dataset of untampered blockchains (that is, blockchains whose production of blocks has been continuous). In Sect. 4.2 we then show how an attempt to change a block is likely to be detected, especially if a substantial portion of blocks must be rewritten to maintain the internal consistency of the blockchain data structure.
A more subtle attacker might try to adjust the times of blocks to hide the change. In Sect. 4.3 we show how this attack may still be detected unless the attacker is able to keep the change in block times very minimal; we note that keeping the block production timestamps within this level slows down how quickly the new blockchain could be forged, and thus gives administrators more time to recognize the discrepancy. All code and data samples are available at https://github.com/taustin/hardenedLogger.
4.1 Untampered Blockchain Dataset
To generate a sample untampered blockchain, we ran SpartanGold with one message per block until 1000 blocks were created. We repeated this process 30 times to create our dataset of untampered blockchains. The dataset was generated on a MacBook Pro with an Apple M1 Pro chip with 10 cores, 16 GBs of memory, and running OSX V.12.4. We used SpartanGold v. 1.0.7. The proof-of-work target was fixed at 19 leading zeroes (binary).
Each block was printed in JavaScript Object Notation (JSON). A sample block is shown below, modified for readability:
![figure c](http://media.springernature.com/lw685/springer-static/image/chp%3A10.1007%2F978-3-031-24049-2_6/MediaObjects/539328_1_En_6_Figc_HTML.png)
The first hash is the block ID. Similar to Bitcoin, the IDs are generated in the search for a valid proof-of-work; as a result, these IDs always begin with several leading zeroes.
The timestamp field identifies when the search for a proof-of-work for the block began. Contrasting this value with the timestamp of the next block indicates the total time that was required to find a valid proof.
In SpartanGold, the proof-of-work is discovered by initializing the proof field to 0 and then incrementing that field until the hash value meets the proof-of-work target. Since we search through the space of proofs sequentially, there should be a positive correlation between the proof and the duration needed to find the block. Of course, an attacker would not have to follow this rule and could search the space of possible proofs in any order that they desired.
Table 1 shows the average time to produce a block and the standard deviation for all of the sample blockchains in our untampered dataset. Results are reported with a precision of 5 digits.
4.2 Simple Attack
For our first experiment, we simulate an unsophisticated attack where the intruder attempts to rewrite a portion of the blockchain and continue the logs from that branch of the blockchain.
To simulate this attack, we introduced a pause at a randomly selected block before the block production was allowed to continue. As with our benign dataset, we produced 1000 blocks for each blockchain sample. For each of these blockchains, a block in the range of 25–975 was selected randomly for the delay. Other applications and system processes were allowed to run, simulating a realistic environment.
When the LoggingMiner class constructor is initialized, we specify the field compromisedBlockNumber to indicate which block should be delayed; the duration of the delay is specified in the compromiseDuration field. At the beginning of the startNewSearch method, we introduce a check to see if the search should be delayed; if so, setTimeout is called to reinvoke the method after the delay. The compromisedBlockNumber is then deleted to allow the new call to continue as normal, and we return from the method to prevent the search from beginning earlier. After this check, the method runs as per normal. The code is shown below:
![figure d](http://media.springernature.com/lw685/springer-static/image/chp%3A10.1007%2F978-3-031-24049-2_6/MediaObjects/539328_1_En_6_Figd_HTML.png)
When the delay was set to 5 min, the compromised block took the greatest amount of time in two cases, and was among the 3 slowest blocks to be produced in all cases. The results for a five-minute delay are summarized below.
File | Time to mine block | Order (out of 1000) |
---|---|---|
blockchain-rewritten1-05.json | 301414 ms | 3rd |
blockchain-rewritten2-05.json | 302700 ms | 1st |
blockchain-rewritten3-05.json | 301815 ms | 1st |
blockchain-rewritten4-05.json | 303038 ms | 3rd |
blockchain-rewritten5-05.json | 305717 ms | 2nd |
We can improve the results by making the logging process a higher priority. When we use the Unix nice command with a priority of -10Footnote 5, the compromised block is the slowest to be produced in all but one of our test cases, as shown below.
File | Time to mine block | Order (out of 1000) |
---|---|---|
blockchain-rewritten1-05-HP.json | 300339 ms | 1st |
blockchain-rewritten2-05-HP.json | 306931 ms | 1st |
blockchain-rewritten3-05-HP.json | 302706 ms | 1st |
blockchain-rewritten4-05-HP.json | 302156 ms | 2nd |
blockchain-rewritten5-05-HP.json | 305554 ms | 1st |
We note that 5 min is also relatively recent activity. The deeper the change is in the blockchain, the more likely it is that this attack would be detected. These analyses do not attempt to account for the nonces, which would be positively correlated with the proof-of-work. It also does not account for other activity on the system. More careful analysis could consider these factors.
4.3 Subtle Attack
When the attacker attempts to recreate the blockchain by interrupting the creation of a block for a fixed amount of time, the machine learning model is immediately able to recognize the discrepancy between the block ID and the amount of time required to compute it. The detection rate, in this case, reaches an accuracy close to 100%. The attacker needs a more subtle approach. Instead of adding a fixed pause before computing new blocks, we introduce a pause that lasts a different amount of time for each block. To simulate this, we modified the timestamp of every recreated block by adding to the timestamp of the previous block a random value selected from a specified range and, then, using this as the timestamp of the current block. Note that the new timestamp cannot be less than the timestamp of the previous block, that is, the new timestamp and the previous one differ a specified number of milliseconds between 1 to the upper bound of the range. For example, the attacker pauses the process for a random number of milliseconds taken from the range 1 to 60000 (one min). In this way, the model processes timestamp differences, that is, the distance between the current timestamp’s block and the previous one, that are not fixed and that vary randomly each time to imitate a more realistic scenario.
In Fig. 2, we see the results of this experiment while varying the upper bound of the range from which the number of milliseconds are selected (from 1 to 180 s). We notice that, when the ranges are close to the legitimate average of the timestamp’s distances, the detection of a compromised block becomes unreliable. This range is highlighted in red and is comprised between 2 and 8 s.
5 Discussion and Future Work
In this paper, we have shown how a logger with a local blockchain can be used to detect log tampering. We have shown that a simple attack that only restarts the blockchain log from a given block is easily detected, and a more subtle attacker can only succeed by moving slowly, and thus opening themselves to a longer window of detection while they rewrite the blockchain.
While we have focused on a single miner, we could easily expand the system to write to multiple mining processes, or even to broadcast out to external blockchain networks. which would strengthen the defenses of the log. An interesting future direction of this research is to do so in a way that uses external blockchains to strengthen the log’s defenses, but can do so in a cost-effective manner.
We are also interested in further understanding the types of attacks that the attacker could perform, and to further study detection techniques capable of identifying these attacks.
Increased accuracy in detection could be achieved by applying different machine learning techniques such as Profile Hidden Markov Models and Ensemble Learning. The model could be trained on sequences of blocks’ information to increase the ability to detect tampering. Furthermore, the hash ID can be combined with additional block information to find the best combination of training inputs to achieve both higher accuracy and higher efficiency.
Notes
- 1.
We note that the original Bitcoin whitepaper [23] did not coin the term “blockchain”; rather, the author refers to a “chain of blocks”.
- 2.
- 3.
- 4.
The miner’s initial balance of coins (line 40) is required; since no coins are used in transactions, the specific balance is not particularly important.
- 5.
With the nice command, 0 is a normal priority task, 20 is the lowest priority, and -20 is the highest priority.
References
Ahmad, Z., Shahid Khan, A., Wai Shiang, C., Abdullah, J., Ahmad, F.: Network intrusion detection system: a systematic study of machine learning and deep learning approaches. Trans. Emerg. Telecommun. Technol. 32(1), e4150 (2021)
Ali, M., Nelson, J.C., Shea, R., Freedman, M.J.: Blockstack: a global naming and storage system secured by blockchains. In: USENIX Annual Technical Conference, pp. 181–194. USENIX Association (2016)
Anderson, J.P.: Computer security threat monitoring and surveillance. James P. Anderson Company, Technical report (1980)
Austin, T.H.: Spartangold: a blockchain for education, experimentation, and rapid prototyping. In: Silicon Valley Cybersecurity Conference (SVCC) (2020)
Back, A.: Hashcash - a denial of service counter-measure, Technical report. http://www.hashcash.org/papers/hashcash.pdf (2002)
Chen, F., Wan, H., Cai, H., Cheng, G.: Machine learning in/for blockchain: future and challenges. Can. J. Stat. 49(4), 1364–1382 (2021)
Chen, J., Gorbunov, S., Micali, S., Vlachos, G.: Algorand agreement: super fast and partition resilient byzantine agreement. IACR Cryptol. ePrint Arch. 2018, 377 (2018)
Chen, X., Ji, J., Luo, C., Liao, W., Li, P.: When machine learning meets blockchain: a decentralized, privacy-preserving and secure design. In: 2018 IEEE International Conference on Big Data (Big Data), pp. 1178–1187. IEEE (2018)
Dong, B., Wang, X.: Comparison deep learning method to traditional methods using for network intrusion detection. In: 2016 8th IEEE International Conference on Communication Software and Networks (ICCSN), pp. 581–585. IEEE (2016)
Filecoin: A decentralized storage network. Technical report, Protocol Labs (2017)
Goodman, L.: Tezos - a self-amending crypto-ledger. Technical report, Tezos Foundation (2014)
Hanke, T., Movahedi, M., Williams, D.: DFINITY technology overview series, consensus system. CoRR abs/1805.04548 (2018). http://arxiv.org/abs/1805.04548
Huang, E., Di Troia, F., Stamp, M.: Evaluating deep learning models and adversarial attacks on accelerometer-based gesture authentication. arXiv preprint arXiv:2110.14597 (2021)
Khan, A.A., Khan, M.M., Khan, K.M., Arshad, J., Ahmad, F.: A blockchain-based decentralized machine learning framework for collaborative intrusion detection within UAVs. Comput. Netw. 196, 108217 (2021)
Kiayias, A., Russell, A., David, B., Oliynykov, R.: Ouroboros: a provably secure proof-of-stake blockchain protocol. In: Advances in Cryptology - CRYPTO 2017–37th Annual International Cryptology Conference, Proceedings, Part I, pp. 357–388 (2017)
King, S.: Primecoin: Cryptocurrency with prime number proof-of-work. http://primecoin.org/static/primecoin-paper.pdf (2013)
King, S., Nadal, S.: Ppcoin: Peer-to-peer crypto-currency with proof-of-stake. http://primecoin.org/static/primecoin-paper.pdf (2012)
Lamport, L.: Paxos made simple, fast, and byzantine. In: Procedings of the International Conference on Principles of Distributed Systems. OPODIS, vol. 3, pp. 7–9. Suger, Saint-Denis, rue Catulienne, France (2002)
Liu, Y., Yu, F.R., Li, X., Ji, H., Leung, V.C.: Blockchain and machine learning for communications and networking systems. IEEE Commun. Surv. Tutorials 22(2), 1392–1431 (2020)
Merkle, R.C.: Protocols for public key cryptosystems. In: 1980 IEEE Symposium on Security and Privacy, pp. 122–122 (1980)
Merrill, P., Austin, T.H., Thakker, J., Park, Y., Rietz, J.: Lock and load: a model for free blockchain transactions through token locking. In: IEEE International Conference on Decentralized Applications and Infrastructures (DAPPCON). IEEE (2019)
Miller, A., Juels, A., Shi, E., Parno, B., Katz, J.: Permacoin: repurposing bitcoin work for data preservation. In: IEEE Symposium on Security and Privacy, pp. 475–490. IEEE (2014)
Nakamoto, S.: Bitcoin: A peer-to-peer electronic cash system (2008). https://bitcoin.org/bitcoin.pdf. Accessed XX Oct 20XX
Namecoin homepage. https://namecoin.org/. Accessed June 2022
Park, S., Pietrzak, K., Kwon, A., Alwen, J., Fuchsbauer, G., Gazi, P.: Spacemint: a cryptocurrency based on proofs of space. IACR Cryptol. ePrint Arch. 2015, 528 (2015)
Saber, A., Di Troia, F., Stamp, M.: Intrusion detection and CAN vehicle networks. In: Montasari, R., Jahankhani, H., Hill, R., Parkinson, S. (eds.) Digital Forensic Investigation of Internet of Things (IoT) Devices. ASTSA, pp. 125–154. Springer, Cham (2021). https://doi.org/10.1007/978-3-030-60425-7_5
Storj: A decentralized cloud storage network framework. Technical report, Storj Labs Inc. (2018)
Tendermint documentation. https://tendermint.com/docs/tendermint-core/running-in-production.html#dos-exposure-and-mitigation (2018)
Vorick, D., Champine, L.: Sia: Simple decentralized storage. Nebulous Inc, Technical report (2014)
Wood, G.: Ethereum: a secure decentralised generalised transaction ledger. https://gavwood.com/paper.pdf (2014)
Author information
Authors and Affiliations
Corresponding author
Editor information
Editors and Affiliations
Rights and permissions
Open Access This chapter is licensed under the terms of the Creative Commons Attribution 4.0 International License (http://creativecommons.org/licenses/by/4.0/), which permits use, sharing, adaptation, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons license and indicate if changes were made.
The images or other third party material in this chapter are included in the chapter's Creative Commons license, unless indicated otherwise in a credit line to the material. If material is not included in the chapter's Creative Commons license and your intended use is not permitted by statutory regulation or exceeds the permitted use, you will need to obtain permission directly from the copyright holder.
Copyright information
© 2022 The Author(s)
About this paper
Cite this paper
Austin, T.H., Di Troia, F. (2022). A Blockchain-Based Tamper-Resistant Logging Framework. In: Bathen, L., Saldamli, G., Sun, X., Austin, T.H., Nelson, A.J. (eds) Silicon Valley Cybersecurity Conference. SVCC 2022. Communications in Computer and Information Science, vol 1683. Springer, Cham. https://doi.org/10.1007/978-3-031-24049-2_6
Download citation
DOI: https://doi.org/10.1007/978-3-031-24049-2_6
Published:
Publisher Name: Springer, Cham
Print ISBN: 978-3-031-24048-5
Online ISBN: 978-3-031-24049-2
eBook Packages: Computer ScienceComputer Science (R0)