Background:
I have developed a software which runs on Linux and I distribute licenses for it to work.
For Linux installations I am using system UUID and my license is based on that.
For installing on various Cloud setups, I am packaging the OS with my software and providing to the User. User deploys it and requests license based on UUIDs shown in my software.
Issue:
When User deploys each instance, in few Cloud setups, UUIDs are same for different VM instances on same physical machine.
This causes a problem for license.
Solution:
What I have planned to do is simple: when OS boots up first time call uuidgen and generate UUID and store it to a file. After that for next reboot I will take it from this file so UUID will be same for the machine.
Questions on above solution:
1
uuidgen with random option calculates uuid by utilizing /dev/random
In a VM setup since there is no direct hardware access for generating this random seed, can /dev/random value possibly be same in different VM instances? which means uuidgen will operate on same seed?
2
if UUID generated in two different linux systems by uuidgen during first time bootup are same because the random seed was not good enough, then the next UUID generated will also be same in those Linux systems?
i.e.
While booting up, uuidgen is called and produces a UUID1 in VM1. Say it is same as UUID2 when uuidgen was called in another VM instance VM2.
If uuidgen is called again for next UUID in VM1, will it be again same if called in VM2?
Thank you.
The most probable thing to investigate is if the customer has generated those VM images from a common one, in which the uuid has already been generated. Having the lenght a uuid has, it's most improbable that you produce a colission of uuids.
By the way, requiring your software to depend on the uuid stored in a file allows your customer to clone your VM after your software has been installed, and all licenses validated by cloning.
If you want to protect your software licenses on VMs, you'll have to do some connecting to a license server and do some public key signing feature to validate licenses.
The main problem is that two cloned images from a virtual machine are exactly equal (hardware and software) and as so, can run the same software without having any difference from the point in time they where cloned.
Related
My code (C++ on Linux) needs to uniquely identify the machine (vm guest/container/physical) that it is running on, and I have been researching TPM (2) for this purpose. Since each physical TPM has a unique EK it seems that I could use the TPM API to verify the machine actually running on is the one expected.
However, with VM's/containers, it seems like a virtual TPM can be copied along with the guest/container to another hypervisor/host. In that case, I assume the EK is copied along with it and this defeats the ability to unique identify the machine (vm guest/container/physical) on which my code runs.
Is this correct? Or do virtual TPM's somehow connect to the host TPM to ensure uniqueness? If someone wanted to bypass my check, I assume running a TPM simulator would have the same effect?
Xen has the ability to attach virtual trusted platform modules (vTPMs) to guest VMs: http://wiki.xenproject.org/wiki/Virtual_Trusted_Platform_Module_(vTPM). I would like to know if there is any Openstack integration for this feature - can managed VM for instance be provisioned vTPMs?
I saw something similar for Hyper-V here:
http://specs.openstack.org/openstack/nova-specs/specs/mitaka/approved/hyper-v-vtpm-devices.html
OpenStack provides the following as part of Cloud tenant threat mitigation:
Use separated clouds for tenants, if necessary.
Use storage encryption per VM or per tenant.
OpenStack Nova has a Trusted Filter for Filter Scheduler to schedule workloads to trusted resources only (trusted computing pools), so workloads not requiring trusted execution can be scheduled on any node, depending on utilization, while workloads with a trusted execution requirement will be scheduled only to trusted nodes.
With the following process:
Before you can run OpenStack with XenServer, you must install the hypervisor on an appropriate server .
Xen is a type 1 hypervisor: When your server starts, Xen is the first software that runs. Consequently, you must install XenServer before you install the operating system where you want to run OpenStack code. You then install nova-compute into a dedicated virtual machine on the host.
While XAPI is the preferred mechanism for supporting XenServer (and its deprecated sibling XCP), most existing Xen Project integration with OpenStack is done through libvirt below.
compute_driver = libvirt.LibvirtDriver
[libvirt]
virt_type = xen
Hardware TPM is also supported:
Our solution essentially mimics how one may download software and compute its SHA-256 hash and compare against its advertised SHA-256 hash to determine its legitimacy. It involves using Intel TXT, which is composed of hardware, software, and firmware. The hardware, attached to the platform, called the Trusted Platform Module (TPM)[3], provides the hardware root of trust. Firmware on the TPM is used to compute secure hashes and save the secure hashes to a set of registers called Platform Configuration Registers (PCRs), with different registers containing different measurements. Other components are Intel virtualization technology, signed code modules, and a trusted boot loader called TBOOT1. Essentially the BIOS, option ROM, and kernel/Ramdisk are all measured in the various PCRs. From a bare metal trust standpoint, we are interested in PCRs 0-7(BIOS, option ROM). The kernel/Ramdisk measurements would depend on the image the tenant seeks to launch on their bare metal instance. PCR value testing is provided by an Open Attestation service, OAT[2]. Additional details in references.
with these security considerations:
At the time of this writing, very few clouds are using secure boot technologies in a production environment. As a result, these technologies are still somewhat immature. We recommend planning carefully in terms of hardware selection. For example, ensure that you have a TPM and Intel TXT support. Then verify how the node hardware vendor populates the PCR values. For example, which values will be available for validation. Typically the PCR values listed under the software context in the table above are the ones that a cloud architect has direct control over. But even these may change as the software in the cloud is upgraded. Configuration management should be linked into the PCR policy engine to ensure that the validation is always up to date.
References
Tighten the security of your OpenStack Clouds - OpenStack Superuser
Xen, XAPI, XenServer - OpenStack Configuration Reference - kilo
XenServer - OpenStack
XenServer/XenAndXenServer - OpenStack
XenAPI Specific Bugs : OpenStack Compute (nova)
OpenStack - Xen
Xen via Libvirt - OpenStack Configuration Reference - liberty
Hypervisors - OpenStack Configuration Reference - kilo
OpenStack Docs: Overview of nova.conf
OpenStack Docs: nova.conf - configuration options
OpenStack Docs: Telemetry configuration options
Configure APIs - OpenStack Configuration Reference - kilo
OpenStack Docs: Glossary
Bare-metal-trust - OpenStack
Baremetal driver - OpenStack Configuration Reference - juno
OpenStack Docs: Integrity life-cycle
Current Series Release Notes — Nova Release Notes 16.0.0.0b3.dev171 documentation
Enhanced-Platform-Awareness-OVF-Meta-Data-Import - OpenStack
Example nova.conf configuration files - OpenStack Configuration Reference - kilo
Chapter 7. Configuring a Basic Overcloud using Pre-Provisioned Nodes - Red Hat Customer Portal
Feature Support Matrix — nova 16.0.0.0b3.dev171 documentation
Trusted Computing for Infrastructure (pdf)
What is Hyper.sh | Hyper.sh User Guide
Xen TPM Manager
Supporting Open Source Software Development in SSOs/SDOs
Xen Cloud Platform Virtual
Machine Installation Guide (pdf)
OpenStack Docs: Security hardening
policy.json - OpenStack Configuration Reference - kilo
Appendix B. Firewalls and default ports - OpenStack Configuration Reference - kilo
New, updated and deprecated options in Kilo for Orchestration - OpenStack Configuration Reference - kilo
I have several applications which works together and need to communicate.
These applications can be installed on different host, which can be in different local networks, but all are connected together via a global network.
The host can be Linux (CenOS, Debian, Ubuntu) or Windows (7/10).
Now, I need to identify which host is running an application.
The requirements are :
- every application running on the same host have the same "host ID"
- every "host ID" is unique among all hosts
Since the host can be physical machines, virtual machines or even docker instances, I don't think I can use the hostname as a "global unique ID".
Since the host can be in different local networks, I don't think I can use local IP address as a "global unique ID".
So, which data can I use ? Maybe the Network adapter MAC address ? Is it
guaranteed to be unique, even between multiple instances of the same docker ?
Thanks.
On modern / recent Linux distro, linux generates for you a unique id in the /etc/machine-id file when the system is created the first time. Some distributed services such as etcd rely on this file to identify machines in a cluster.
Nothing prevents you from creating and persisting on disk something like a uuid. You can use uuidgen command on Linux for that.
You can say the MAC address is unique. However, if you are concerned about security, do not use the MAC address. The MAC address can be spoofed easily.
To generate a unique ID for the machine, you can use a combination of many items such as MAC Address, IP Address, hostname etc., throw in a random salt and take a sha256 hash of them. Since the host can run on many operating system, I would suggest against using any OS-specific parameters.
Without going into too much detail, the chances of finding a collision in sha256 is improbable to say the least.
You can see the SHA256 of different text here.
http://www.xorbin.com/tools/sha256-hash-calculator
Almost every programming language, these days, has a function/API for creating a SHA256 hash.
Looks like /var/lib/dbus/machine-id contains what you need.
read more here: http://man7.org/linux/man-pages/man5/machine-id.5.html
On linux I solved my problem just by changing the contents of the /var/lib/dbus/machine-id file
I have a machine with TPM and I am running windows 7 on it.
I have a piece of code and I want to get run it and get the PCR register values at that time.
How can I do that?
Secondly, if i run the same code on other machine can I get the same PCR values? If I cannot then is there anyway to get it?
-------------- EDITED version Below----------------------
The Scenario is as follows,
I have an executable code written in C++ (for example a simple card game).
I want to run this file on my computer.
I want to get the PCR values.
Windows platform has 24 PCR register, Now which register has the hash of my running file (game)?
Without detailed information I can just provide a general answer. I will edit it if you provide more details.
Reading PCRs
There is a low-level Windows API you can use. Look at this question and its answer:
Controlling TPM with C#.
Basically look at the documentation of TPM Base Services (TBS). You will need to implement the read command on your own.
If you have a Java application, use JSR321 or jTSS.
There is an experimental port of TrouSerS for Windows.
Comparison of PCRs
A TPM on a PC platform will have 24 PCRs. In almost all cases the set of all 24 will not be the same on two different machines. In general you cannot alter it's values, especially not the "lower" ones representing firmware measurements. I guess what you are looking for is information whether a remote PC is in a trusted state or not. That's the holy grail. Get some literature on Trusted Computing and search the web for "trusted computing + attestation".
I've been reading into virtualization security and came across Blue Pill, a malicious thin hypervisor (project website is down, archived version here: http://web.archive.org/web/20080418123748/http://www.bluepillproject.org/).
My question is: could a custom malicious hypervisor modify execution flow, inject and execute arbitrary code, look at private information in RAM of the VM or anything else?
I'm not asking whether this would be practical from a malware point of view (to implement these features, it may turn into a large and impractical backdoor). I'm interested in whether the malicious hypervisor would have complete control over every aspect of the virtualized machine.
Would there be any difference for this when it comes to a program like VirtualBox - could the Host OS execute arbitrary code inside the guest at any time it choses?
Any thoughts would be highly appreciated!
Thanks in advance,
r3mo
Yes, the hypervisor is running at a higher privilege level than the guest VM so it could easily modify the execution flow and read arbitrary parts of the VM.
The same is true for VirtualBox. The host OS can alter the guest provided that you have full access/permissions on the host OS.