I am wondering if it's possible to program TPM ( http://en.wikipedia.org/wiki/Trusted_Platform_Module ) present in most of Intel chips, in such a way to:
- decide what to store in the persistent memory
- decide which cryptographic algorithms to implement.
Obviously it should not be reprogrammable once that it starts working (are you aware if this statement is correct?).
The behaviour of a TPM is defined by the specifications issued by the Trusted Computing Group. A TPM must exactly behave as specified, so you cannot change the functionality of a proper implemented TPM. The manufacturers of TPMs have limited abilities to update their products after shipping. For example Infineon provides firmware updates for their devices.
Intel TPMs however may be different. Some chipsets included an emulated/software TPM instead of an actual hardware TPM. Those TPMs can be updated with a BIOS update. But also in this case the update has to be provided by Intel. Recent boards like the DQ67SW have stand alone hardware TPMs not manufactured by Intel.
So the answer to your second question is: No, you cannot program/define the cryptographic algorithms a TPM uses.
Regarding your first question: Yes, you can define what to store in the persistent storage to some extend. This memory region is called Non-volatile Storage or NV. You have to define some space first using the TPM_NV_DefineSpace command. Afterwards you can read and write from/to the location using TPM_NV_ReadValue and TPM_NV_WriteValue. Defining reserves a given amount of memory in NV and also sets up the security attributes of this location. Those commands are low-level TPM commands, it is highly recommended to use a Trusted Software Stack (TSS) to interface the TPM. You can use either jTSS with jTpmTools or TrouSerS.
Some notes regarding NV:
There is very limited space in the NV, but the exact amount is vendor specific (usually less than 5kb). The minimum amount for the PC platform is 2048 bytes.
The TPM is a passive device, it cannot do anything without a command issued to it. If you want to store something in the TPM, you have to have some active piece (BIOS, Software, Chipset, CPU) that issues those commands.
Even most cryptographic keys are not stored within the TPM. There is a key hierarchy and only the root key (Storage Root Key - SRK) is stored in the TPM. All other keys are stored outside in an encrypted way.
The TPM is not intended to be programmable. It has a fixed set of supported algorithms. The code is stored in ROM (or if it isn't, it is stored in an EEPROM that is inside a somewhat tamper-proof package and you don't get to overwrite it).
The TPM defines various administrative roles. When you first use it, you'll set up administrative passwords (or your software will do it for you, in which case you should carefully back up these passwords). If you are unsure about the state of the TPM when you receive it, you can reset it to “factory defaults” (clearing all existing keys and credentials); this is called clearing the TPM and is normally done from the BIOS.
You'll find an overview of the various credentials stored and used by the TPM in the credential profiles. In addition to the keys that are part of the normal lifecycle, you can import your own keys and create non-exportable keys with the TPM's RNG.
There is a standard TPM protection profile. I don't know if Intel's TPM has been evaluated with respect to it. Figure 1 is a diagram of the TPM lifecycle, which shows when keys can be generated.
In practice, you'll probably interact with the TPM through TrouSerS (a fully open source TPM API), or in a limited fashion through Bitlocker on Windows.
Yes, you can use the TPM chip for exactly these sorts of operations, and many more.
The TrouSerS stack is an open source implementation of the trusted computing software stack necessary for using the TPM chip reliably.
Related
I need to implement an authentication procedure between a reader an NFC tag but being my knowledge limited in this area I will appreciated some aid in order to understand few concepts.
Pardon in advance for rewrite the Bible but I could not summarize it more.
There are many tags families ( ICODE, MIFARE, NTAG...) but after doing a research I think NTAG 424 DNA matches my requirements(I need mainly authentication features).
It comes with AES encryption, CMAC protocol and 3-pass-authentication system and here is when I started to need assistance.
AES -> As I am concerned this is a block cipher to encrypt plain texts via permutations and mapping. Is a symmetric standard and it does not use the master key, instead session keys are used being them derivations from the master key. (Q01: What I do not know is where this keys are stored in the tag. Keys must be stored on specialized HW but no tag "specs" remark this, apart from MIFARE SAM labels.)
CMAC -> It is an alteration of CBC-MAC to make authentication secure for dynamically sized messages. If data is not confidential then MAC can be used on plain-texts to verify them, but to gain confidentiality and authentication features "Encrypt-than-mac" must be pursuit. Here also session keys are used, but not the same keys used in the encryption step.(Q02: The overall view of CMAC may be a protocol to implement verification along with confidentiality, this is my opinion and could be wrong.)
3-pass-protocol -> ISO/IEC 9798-2 norm where tag and reader are mutually verified. It may also use MAC along with session keys to achieve this task.(Q03: I think this is the upper layer of all the system to verify tags and readers. The "3 pass protocol" relays in MAC to be functional and, if confidentiality features are also needed, then CMAC might be used instead of single MAC. CMAC needs AES to be functional, applying session keys on each step. Please correct me if I am posting savages mistakes)
/*********/
P.S: I am aware that this is a coding related forum but surely I can find here someone with more knowledge than me about cryptography to answer this questions.
P.S.S: I totally do not know where master and session keys are kept in the Tag side. Have they need to be include by a separate HW along with the main NFC circuit ?
(Target)
This is to implement a mutual verification process between tag and reader, using the NTAG 424 DNA TagTamper label. (The target is to avoid 3º parties copies, being authentication the predominant part instead of message confidentiality)
Lack of knowledge of cryptography and trying to understand how AES, CMAC and the mutual authentication are used on this NTAG.
(Extra Info)
NTAG 424 DNA TT: https://www.nxp.com/products/identification-security/rfid/nfc-hf/ntag/ntag-for-tags-labels/ntag-424-dna-424-dna-tagtamper-advanced-security-and-privacy-for-trusted-iot-applications:NTAG424DNA
ISO 9798-2: http://bcc.portal.gov.bd/sites/default/files/files/bcc.portal.gov.bd/page/adeaf3e5_cc55_4222_8767_f26bcaec3f70/ISO_IEC_9798-2.pdf
3-pass-authentication:https://prezi.com/p/rk6rhd03jjo5/3-pass-mutual-authentication/
Keys storage HW:https://www.microchip.com/design-centers/security-ics/cryptoauthentication
The NTAG424 chips are not particularly easy to use, but they offer some nice features which can be used for different security applications. However one important thing to note, is that although it heavily relies on encryption, from an implementation side, that is not the main challenge, because all of the aes encryption, cmac computation and so on is already available as some sort of package or library in most programming languages. Some examples are even given by nxp in their application note. For example in python you will be able to use the AES package from Crypto.Cipher import AES as stated in one of the examples of the application note.
My advice is to simply retrace their personalization example beginning at the initial authentication, and then work your way up to whatever you are trying to achieve. It is also possible to use these examples in order to test the encryption and the building of apdu commands. Most of the work is not hard, but sometimes the NXP documents can be a bit confusing.
One small note, if you are working with python, there is some code available on github which you might be able to reuse.
For iOS, I'm working on a library for DNA communication, NfcDnaKit:
https://github.com/johnnyb/nfc-dna-kit
I recently read about decompilation of iOS apps and I'm now really concerned about it. As stated in the following posts (#1 and #2) it is possible to decompile an iOS which is distributed to the App Store. This can be done with jailbreak and I think with copying the app from memory to hdd. With some tools it is possible to
read out strings (strings tools)
dump the header files
reverse engineer to assembly code
It seems NOT to be possible to reverse engineer to Cocoa code.
As security is a feature of the software I create, I want to prevent bad users from reconstructing my security functions (encryption with key or log in to websites). So I came up with the following questions:
Can someone reconstruct my saving and encryption or login methods with assembly? I mean can he understand what exactly is going on (what is saved to which path at which time, which key is used etc., with what credentials is a login to which website performed)? I have no assembly understanding it looks like the matrix for me...
How can I securly use NSStrings which cannot be read out with strings or read in assembly? I know one can do obfuscation of strings - but this is still not secure, isn't it?
This is a problem that people have been chasing for years, and any sufficiently-motivated person with skills will be able to find ways to find out whatever information you don't want them to find out, if that information is ever stored on a device.
Without jailbreaking, it's possible to disassemble apps by using the purchased or downloaded binary. This is static inspection and is facilitated with standard disassembly tools. Although you need to have a tool which is good enough to add symbols from the linker and understand method calls sufficiently to be able to tease out what's going on. If you want to get a feel for how this works, check out hopper, it's a really good disassembly/reverse-engineering tool.
Specifically to your secure log in question, you have a bigger problem if you have a motivated attacker: system-based man-in-the-middle attacks. In this case, the attacker can shim out the networking code used by your system and see anything which is sent via standard networking. Therefore, you can't depend on being able to send any form of unencrypted data into a "secure" pipe at the OS or library level and expect it not to be seen. At a minimum you'll need to encrypt before getting the data into the pipe (i.e. you can't depend on sending any plain text to standard SSL libraries). You can compile your own set of SSL libraries and link them directly in to your App, which means you don't get any system performance and security enhancements over time, but you can manually upgrade your SSL libraries as necessary. You could also create your own encryption, but that's fraught with potential issues, since motivated hackers might find it easier to attack your wire protocol at that point (publicly-tested protocols like SSL are usually more secure than what you can throw together yourself, unless you are a particularly gifted developer with years of security/encryption experience).
However, all of this assumes that your attacker is sufficiently motivated. If you remove the low-hanging fruit, you may be able to prevent a casual hacker from making a simple attempt at figuring out your system. Some things to avoid:
storing plain-text encryption keys for either side of the encryption
storing keys in specifically named resources (a file named serverkey.text or a key stored in a plist with a name which contains key are both classics)
avoid simple passwords wherever possible
But, most important is creating systems where the keys (if any) stored in the application themselves are useless without information the user has to enter themselves (directly, or indirectly through systems such as OAUTH). The server should not trust the client for any important operation without having had some interaction with a user who can be trusted.
Apple's Keychain provides a good place to store authentication tokens, such as the ones retrieved during an OAUTH sequence. The API is a bit hard to work with, but the system is solid.
In the end, the problem is that no matter what you do, you're just upping the ante on the amount of work that it takes to defeat your measures. The attacker gets to control all of the important parts of the equation, so they will eventually defeat anything on the device. You are going to need to decide how much effort to put into securing the client, vs securing the server and monitoring for abuse. Since the attacker holds all of the cards on the device, your better approach is going to be methods that can be implemented on the server to enhance your goals.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 7 years ago.
Improve this question
I am researching Key Management Solutions in order to become PCI compliant. I have spoken to a number of vendors in the arena, and while I like their products, the cost is beyond my budget. Is anyone aware of any open source or low cost solutions for Key Management? I use a Windows/.NET environment, so I would prefer solutions that target that environment, however I would be interested in hearing about anything that is out there.
Thanks
Take a look at KeyManager, which is the key management component of the OpenStack suite. The application can be used as a stand-alone key management solution outside of OpenStack.
Being a component of OpenStack, KeyManager is being actively developed with new features planned on six month cycles.
We had a similar experience as you. We needed a key management solution for PCI compliance and all the commercial products we saw were too expensive. Some key managers cost more than our product for small customers!
We ended up making a software based key manager. We made requirements and offshore developers coded it. At one time they were looking for other customers to use it. I don't know if they still are or not.
Let me explain the options we explored. First thing to remember is that PCI compliance and security are different things, you can be PCI compliant and not very secure.
Option 0 - Assign a key per DB column, and store keys in a DLL file. Your application links in the DLL file to access the keys to encrypt and decrypt the data. No one knows the keys. For periodic key replacement you make a new DLL with new keys, take down time to decrypt all data using old keys and reencrypt data using new keys. Then restart your application using the new DLL with new keys. (Note if you ever consider restoring a DB backup, you need to keep the old keys.)
The first time I heard about Option 0 I was surprised it was PCI compliant. We do not use Option 0.
Ways to improve on Option 0.
If you have an HSM in your environment, use the HSM to encrypt the keys in the DLL file. When your application starts it will decrypt the keys using the HSM. If you want more security, decrypt the keys every time they are needed.
Once your keys are encrypted, it is safe to store them in a DB table. If you assign each key (old and new) a small integer key-id, you can store the key-id with the encrypted data. That lets you do incremental key replacement and avoid down time.
Having your keys in the clear in memory in lots of processes, increases your exposure to a memory scan attack finding the keys. You can create a new process that is the only process that decrypts the keys. Your applications talks to this new process to encrypt and decrypt data. This new process should be on a box with a small "surface area" to protect it. Since sensitive data is going over the network now, this communications should be encrypted. SSL is a good option.
I realize this is an old thread, but there are couple of options:
A completely free and open-source key-management solution is at http://sourceforge.net/projects/strongkey. I will admit, the software is a little dated and is fairly complex to setup because it assumes you have a PKI to issue digital certificates to application clients for communicating with the key-management server, and for securing keys on the client device.
The original StrongKey software was simplified drastically three years ago and integrated into an appliance with a cryptographic hardware module (TPM and HSM) to provide stronger key-management. Unfortunately, even though the software on the appliance is all FOSS, the integrated solution itself is not free - its price is listed on its website (http://www.strongauth.com/products/key-appliance.html).
However, there are many advantages with option #2 as it allows you to leverage Public Clouds while being fully PCI-compliant (search for "Regulatory Compliant Cloud Computing (RC3)" and click on the link at IBM - I can only post two links in my answer) with more announcements about how to leverage this appliance being announced at RSA 2013 in San Francisco.
I hope that helps.
KLMS over KMIP is good and easy to use solution for key management.
This is an open source solution written in Java. See the below link for reference. http://www.ibm.com/developerworks/library/se-kmip4j/
The package named stubInterface will contains all the api required to use KLMS over KMIP.
KLMS: Key Lifecycle Management Systems
KMIP: Key Management Interoperability Protocol
I will add to this list as I found it in a search and others may benefit from an expanded list.
I have recently found KeyWhiz which appears to be in alpha.
SNipeit is the best one I have seen that is open source, very robust, and very easy to use, even for non-techies.
https://snipeitapp.com/demo/
Check it out there.
In my company, we are developing against a local server, we do not keep a copy of the file-base on our personal laptops given by the company, that we take home.
There are 2 problems with that:
We can't work remotely efficiently.
File search (find + quick find in NetBeans, which I use a lot) is very slow.
What options do I have of securing the source code on my laptop to save it from thieves / hackers that may or may not lay hands on my laptop?
I recommend TrueCrypt, as it's easy to use, free, open-source, and works both on Windows and Linux.
It encrypts/decrypts on the fly, with no temporary "plain text" files.
You can just create an encrypted container or encrypt an entire drive, but I suspect a file container is enough in your case, as you need to protect just the source code (ie httpdocs folder).
It has an option to automatically dismount the container when locking the computer (WIN+L on Windows) so you would also instantly be protected when you leave your laptop (at a client's location, for example).
Choose one of the encryption methods (they're all strong encryption
algorithms - I prefer AES, as it's faster and it's the current
standard, but you can go with another one or a combination of 2-3
algos) and hashing method (I would suggest SHA-512 over the default RIPEMD-160)
Make sure you use a strong password (master key) when creating the
container
And make sure to backup your container file if you plan to
work for a while without commiting to SVN/Git. In case of hard-disk
failure, encrypted data is harder to recover (if not impossible in
some situations)
Well, one obvious option is to use the encryption. Keys used in modern crypto-tools are now long enough that it would take decades for some hacker to break it (I would assume here that you won't be a victim of NSA attack, even though they would probably have a hard time breaking a 1024 or 2048 bit key :-))
Which tool to choose mostly depends on your OS and budget. Good news is that there are many reliable free programs for such purpose, you can find lists of them here, here and here. Good luck.
Imagine that a large player is undertaking the construction of a new operating system, where backward compatibility requirements are limited to:
Run existing applications written in (or compiled to) JavaScript which are presented in HTML5 and styled with CSS3
Plug and play support for printers, external storage, and optical drives
Degrade gracefully when disconnected from the internet
Sufficient process quotas to support safely permitting tasks to run in the background, including timers
What specific features from existing research operating systems (such as Plan 9) would you like to see enter the mainstream through this channel? Please limit your suggestions to things that have been implemented, and provide a link to the implementation (or at least search terms).
From the Plan 9 docs:
Plan 9 began in the late 1980’s as an
attempt to have it both ways: to build
a system that was centrally
administered and cost-effective using
cheap modern microcomputers as its
computing elements.
Netbooks qualify as cheap modern microcomputers, and The Cloud qualifies as centrally administered. There is an opportunity to implement the features (in DDaviesBrackett's words) that we want netbooks to have other than by extending a 1970's time-sharing OS; the research operating systems may have proved the value of alternatives by example.
From the Plan 9 FAQ:
Subject: What are its key ideas?
Plan 9 exploits, as far as possible,
three basic technical ideas: first,
all the system objects present
themselves as named files that are
manipulated by read/write operations;
second, all these files may exist
either locally or remotely, and
respond to a standard protocol; third,
the file system name space - the set
of objects visible to a program - is
dynamically and individually
adjustable for each of the programs
running on a particular machine. The
first two of these ideas were
foreshadowed in Unix and to a lesser
extent in other systems, while the
third is new: it allows a new
engineering solution to the problems
of distributed computing and graphics.
Plan 9's approach means that
application programs don't need to
know where they are running; where,
and on what kind of machine, to run a
Plan 9 program is an economic decision
that doesn't affect the construction
of the application itself.
Does that not appear to be an excellent fit for the netbook/Cloud domain?
What operating system features I would advocate for Chrome OS?
Here my wish list as a Plan 9/Inferno fan:
Resources (ip stack, graphics, etc) as file systems.
Network transparent file system (ie., 9P).
Private per-process namespaces.
Factotum-like auth system (ie., no root user).
Pure UTF-8 everywhere.
Extremely lightweight processes.
Automatic snapshot and de-duplicating storage (ala venti+fossil).
And I guess many others, but this would be enough to make me quite happy.
This is not a 'OS feature' per see, but I would love to have a GUI with mouse-chording.
None.
I'd prefer for a new consumer OS, especially one targeted at Netbooks, to be very very good at doing the things that we already want OSes to be able to do rather than having time spent on features that are, by their nature, experimental.
(Of course, I'd be totally un-bothered by features I wasn't forced to use to develop on the platform; other people's toys are welcome as long as they don't make my job harder.)
I really think that Google might look into Plan9 for inspiration actually. Hearsay (the Internet) claims that several of those that initially developed UNIX and then later scrapped it for a better design (Plan9) are employed by Google. Google is also hosting its own version of Inferno, but I am not sure whether this is any central part of their plan. Further "evidence" could be that the plan9 authorization system (p9auth) for Linux was published by a Google researcher. The third "evidence" would be that Google claim that Chrome OS will have a novel security architecture.
The authorization seems to me to be one of the GREATEST parts of the Plan9 that can be included right now (/net would also be nice but there is no working code for that yet). The idea that a program that needs root access only gets limited access to the parts that are determined by the authorization server is definitely a great step forward compared to the now prevalent user/superuser/root division in Linux, where "a man in the middle" attacks can (theoretically) be done by gaining (full, as opposed to limited by the authorization server) root access via a bug in a program granted root.