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".
Related
I recently purchased Micro:Bit. I've seen that micro-python and bluetooth cannot be used at the same time due to memory capacity.
Does anyone know if I would be able to build a decent application using the javascript block programming?
The app basically has to do the following:
Read data from acceleretometer.
Acumulate some accelerometer data.
Send the information to another device connected via bluetooth.
Yes, you should be able to write a program for the microbit that does this. the official documentation describes the services that are available. I also found an example which suggests that there is an app which you can use at the phone end if that's relevant to your application.
The micropython restriction is a combination of the BLE protocol stack requiring 12 kB of RAM, and python being interpreted (so having a high RAM requirement).
You can chose the block version or test javascript - and should be able to write reasonably complex programs (even if the text entry might be best done in an editor). As a final fall-back, you can fall back on C/C++ using the microbit DAL (which seems to be built on top of the mbed offline toolchain).
How can I develop applications that use Arm's trust zone? Specifically, I want to develop a program that can save sensitive data in the secure world.
Should this program run in the normal world or the secure world? I know there are trustlets in the secure world, do I need to develop trustlets? Are there SDK or API
that I can use to directly interact with an existing secure world os or do I need to compile and install my own secure os?
Any advice will be greatly appreciated.
Thank you!
There are two extremes. These are documented in the Software overview chapter of ARMs Security Technology: Building a Secure System using TrustZone Technology.
APIs
At the one end of the spectrum, there is only a set of APIs which can be called from the normal world. This is detailed in the SMC calls for Linux. For instance, if the device contains a public-private key, an API call could sign data. The normal world would never have access to the private key, but anyone can verify that the device is original by verifying the signature. So the normal world is free to forward this request over any communications interface. This maybe part of authenticating a device.
Co-operative OSs
In this mode, there is a full blown OS in both the secure and normal world (called TEE and REE elsewhere). The OSs must co-operate with interrupts and scheduling. They may also use SMC calls, lock free algorithms and semaphores along with shared memory.
ARM recommends using the FIQ for the secure world and to leave the IRQ for the normal world. Specifically, there are settings to stop the normal world from masking the FIQ ever. All of these issue rely on the type of IPC, scheduling, interrupt response, etc that the system needs.
The simplest Secure scheduler would always pre-empt the normal world. Only the idle task would yield the CPU to the normal world. A more flexible solution would have the schedulers co-operate so that both worlds can have higher and lower priority tasks.
The better way is install a REE OS and a TEE OS in one device. When a program wants to do some sensitive things, the device will change to TEE OS, so you can deal with sensitive date securely. When you have done with sensitvie date, device will change to REE OS.
But implementing two OS switch on a device is a tough work.
Operating Systems such as MobiCore already exist and have been deployed on mass market devices such as Samsung Galaxy S3.
MobiCore is an OS that runs alongside Android, so trustlets (= MobiCore apps) can communicate with Android apps via a set of system calls to the MobiCore driver, which is the part of the Android OS in charge of communicating with the trusted execution enviromnent.
If you are looking to develop trustlets for MobiCore as explained above, you must become a MobiCore developer, which you could theoretically do by signing up as a developer for MobiCore's Trustonic venture.
If you wish to use ARM's TrustZone technology on your own device / dev board with an open-source secure OS, perhaps you can use OpenVirtualization's SierraTEE, which seems to be compiled for Xilinx Zynq-7000 AP SOC and also compatible with Android as the rich OS.
You can use OPTEE(Open Sourec Portable Trusted Execution environment) OS. If you are looking for trusted execution environment application examples, which are also know Trusted Applications(TA), then you can check this optee trusted applications examples repository and this TA using OP-TEE and Comcast Crypto API.
Optee os provides following APIs for writing Trusted Applications:
Secure Storage APIs for secure storage
Cryptographic Operations APIs for encryptiion, decryption of secure credentials and data
Secure Element API which help in hosting applications or applets on tamper-resistant platform
Time APIs
Arithmetical APIs
For client side or normal world optee provides:
Tee client side Apis
You can refer documentation here.
I am trying to write an snmp agent for RFC 4836, Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs), to run on an embedded Linux system (Linux server 2.6.35.12+). I've used mib2c to set up my frameworks, but am stalled on finding where to get the data to fill in. I am not sure where I should be looking: if the MAU is part of the eth device or a separate interface, if I should be looking somewhere in the /sys or /proc fs, or if I need to access the device registers directly (or both?).
I know there is a lot of different data needed, and am not asking for a roadmap with everything, but at this point I am hung up and not sure where I should be concentrating my efforts - driver code?
Sorry if this seems a dumb question, but I have been looking online and in StackOverflow without finding what I need.
It turned out the information I needed is available from mii-tool. Despite what you may see on the web, this is not obsolete (it may have been a few years ago but it seems to have been updates). Or, you can access the device registers directly using ioctl calls to SIOCGMIIREG, to avoid having to parse command output.
I've spent a lot of time developing an operating system and working on my low level boot loader. But now I want to take some time off my operating system while not leaving the low-level environment and doing something involving security.
So I chose to build my own standard password utility following the pre-boot authentication scheme. Since I want the software to be at least a little portable I want it to use as little external support as is possible. I figured that I'd be best if I somehow managed to 'hook' into the bios somewhere between the self checks and the int 19 bootstrap from within a running real mode OS.
However finding information on how to modify the bios code proved to be impossible. I've found nothing on how to achieve the before mentioned. I have only found pages describing how to flash your bios.
Does anyone know how I can read/write bios code? Or can someone provide links to pages that describe this?
I know that it's not only possible to brick my device but it is also likely, I'm aware of the risk and willing to take it.
Pinczakko's articles on BIOS reverse engineering are a great place to start looking at this. There was also a book published by the same author but it is now out of print.
I'm not sure if this approach is the best approach towards a secure boot, but the articles on this site are very detailed and should point you towards a method for modifying your BIOS firmware.
I'm not really sure what you are trying to achieve, but:
The BIOS is completely hardware specific - each manufacturer will have their own mechanism for updating / flashing BIOS and so trying to come up with a portable mechanism for updating a BIOS is destined for failure. For example when using Bochs you "update" the BIOS by specifying a different BIOS ROM image.
If you want to modifty / write your own BIOS then its going to be completely specific to that hardware. Your best bet would be to start with something like Bochs as its open source - as you can take a look at the source code for the BIOS (and easily test / debug it) you stand a reasonable chance of understanding the BIOS code and modifying it into something that works, however I suspect this isn't what you are trying to do.
Why not just perform this authentication as your OS boots? If you want to protect the data then you should encrypt it and require that the user supply log in / supply the decryption key on startup.
If you were thinking of working with "legacy" PC BIOS, I would dissuade you from trying for many of the reasons Justin mentioned: 1) legacy BIOS is PC vendor-specific; 2) it is closed source and proprietary; 3) there are no industry standards defining legacy BIOS interfaces for extending the system as you are trying to do.
On the other hand, if you have access to a UEFI-based BIOS PC, you may be able to write your own PEI/DXE driver(s) to implement such a feature. This will at least point you in the right direction:
http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=Welcome
Intel Press book on the topic: Beyond BIOS
Regarding the practicality of read/writing the BIOS, you'll need to identify the SPI part containg the BIOS and get a ROM burner. The SPI part may or may not be socketed; if it is not socketed, you'll need a soldering iron and be able to create a socket/header for the part. You obviously do not want to embark on this project with your primary computer system. Perhaps you could find an older system or a reference board.
We have a registered PC based application that needs a Dongle (hardware that gets plugged on the printer port) to start and execute. The vendor who provided us this application and Dongle, does not make or work with these dongles any more, since they are very old technology, and would not help us in this aspect.
So my question is --> is it possible to read the security code from this Dongle and store it in a file or something on the PC. We also do not have the source code of the application. Can we change the call in the application to read the security key from this file instead of trying to read it from the Dongle attached to the printer/parallel port.
Sorry for the vague question but we are very desperate to get help on this problem as out application has 16-bit code and it would not be supported by Windows 7 which is 64 bit. Thanks!!
The LPT security devices don't just contain information but usually include a processor and perform certain operations. Dongle emulators were developed when dongles where more widespread, but as they were based on reverse-engineering, they didn't work exactly right.
To answer your question, no, what you need is not possible. You need to start thinking about migration to another application. A temporary solution would be to have a copy of older OS running in virtual machine and to have your application run in this virtual machine. Such solution will work for another 5-10 years for sure, and I think it's enough for migration.