I want to ask a basic question. I am following story of Alice from Indy offical docs. When Faber College issue identity to Alice then faber college and Alice both know the identity of Alice. It means Faber College maintaning local database of students and assign identity to its students. Which students kept in their wallet. Then how identity is decentralize? Faber college local database might be a honey pot for attackers.
Yes, Faber college will still have the data of Alice in its database. But the whole idea of SSI is to go towards Zero Knowledge Proof. So even if an attacker hacks the database and gets the details it is of no value, an organisation now asks for proof which only Alice can do as she holds the private key to do so. So that's how the honey pot situation is also solved. Hope I answered your query.
In this case Faber College is the identity issuer and Alice is the holder, as an Identity Issuer I would have to know what and who the credentials i am assigning to. i.e. College-Transcript
Identity is decentralized when there is another issuing party, for example Job-Certificate from Government Agent ( by following your example ). From there on the Holder (Alice) would consist of 2 credentials which is 1.Job-Certificate , 2.College-Transcript. Thereon only Alice would have the authority to share a credential supply proof with another party. The link upon Issuer-Holder must exists in order for the Verifier to verify the proof that is supplied later on.
Secondly, the wallet creation may be done by another agent (as all wallet creations are done offchain) faber college would not know the existence of Alice. A connection must be established in anycase for faber college to know the existence of Alice, if so the database would not be on faber college agent.
Don't go for the literal meaning of a decentralized identity. Your question is valid and it's true that your personal identity is not decentralized anyway and SSI is not meant to solve this problem.
So where is decentralization in this identity Picture?
SSI is a citizen-centric decentralized identity model where Public institutions can be part of a decentralized network( Sovrin network) and instead of an identity system managed and control only by Govt, all the participants in the network will maintain, making it distributed, decentralize (consensus) and scalable.
So The identity process is decentralized, not actual an identity of the person.
Coming back to the honeypot issue, When fully SSI layer is implemented, the organization won't have your actual signed verifiable credentials, they may have raw data into their local DB. In the SSI model, when you want to prove your identity, you need to provide verifiable credentials, which nobody can have except you. So anybody having hold of raw data can't use to avail any services thus avoiding identity theft.
But how to stop raw data to be stolen is more of a system security issue rather than SSI or Blockchain.
Related
A digital certificate issuer says that:
- an email will be sent to "registered owners" of the domain (ex. croraf.com).
How does he know who the "registered owners" of the domain are? (and how can I tell in general who the registered owners of some domain are)
NOTE: Below that it gives the option to "send an email to admin#croraf.com, webmaster#croraf.com, hostmaster#croraf.com". So by registered owners it is meant something else (perhaps names in whois lookup of the domain).
The convention is to use hostmaster, postmaster or some other "well-known" email address at a domain which is likely to be held by an entity enabled to act on behalf of that domain.
They may also pull from the whois data. e.g. for stackoverflow.com it would be reasonable to allow the email to be sent to sysadmin-team. The whois data is fairly indicative of someone who is responsible for the domain, because anyone who can cause the domain's whois data to change has the ability to repoint their DNS authority to another service (where they presumably have the ability to modify things), making someone who has "whois-edit" permissions capable of completely subsuming the domain. Therefore, whoever they say is trustworthy is as good as anything else.
I'm interested in creating a challenge / response type process in Delphi. The scenario is this...we have 2 computers...1 belongs to the user and 1 belongs to a support technician.
The user is locked out of a certain program, and in order to gain 1 time access, I want:
The user to be presented with a challenge phrase, such as "28394LDJA9281DHQ" or some type of reasonably unique value
The user will call support staff and read this challenge (after the support staff has validated their identity)
The support person will type this challenge value into a program on their system which will generate a response, something equally as unique as the response, such as "9232KLSDF92SD"
The user types in the response and the program determines whether or not this is a valid response.
If it is, the user is granted 1 time access to the application.
Now, how to do this is my question? I will have 2 applications that will not have networked access to one another. Is there any functionality within Windows that can help me with this task?
I believe that I can use some functionality within CryptoAPI, but I really am not certain where to begin. I'd appreciate any help you could offer.
I would implement a MD5 based Challenge-Response authentication.
From wikipedia http://en.wikipedia.org/wiki/CRAM-MD5
Protocol
Challenge: In CRAM-MD5 authentication, the server first sends
a challenge string to the client.
Response: The client responds with a username followed by a space
character and then a 16-byte digest in
hexadecimal notation. The digest is
the output of HMAC-MD5 with the user's
password as the secret key, and the
server's original challenge as the
message.
Comparison: The server uses the same method to compute the expected
response. If the given response and
the expected response match then
authentication was successful.
This provides three important types of
security.
First, others cannot duplicate the hash without knowing the password.
This provides authentication.
Second, others cannot replay the hash—it is dependent on the
unpredictable challenge. This is
variously called freshness or replay
prevention.
Third, observers do not learn the password. This is called secrecy.
The two important features of this
protocol that provide these three
security benefits are the one-way hash
and the fresh random challenge.
Additionally, you may add some application-identification into the challenge string, for a double check on the sender of the challenge.
Important: it has some weaknesses, evaluate carefully how they may affect you.
Regarding the verbal challenge/response strategy: We used this approach to license a niche application on five thousand workstations world-wide for more than ten years. Our support team called it the "Missile Launch Codes" because of its similarity to the classic missile launch authentication process seen on old movies.
This is an extremely time consuming way to protect your program. It consumed enormous amounts of our staffs' and customers' time reading the codes to and from users. They all hated it.
Your situation/context may be different. Perhaps you won't be using it nearly as frequently as we did. But here are some suggestions:
Carefully consider the length and contents of the code: most users (and support staff) resent typing lots of characters. Many users are bad typists. Consider whether a long string and including punctuation marks and case sensitivity unduly burdens them compared to the amount of security added.
After years of using a verbal challenge/response implementation, we left it in place (as a fall-back) but added a simple automated system. We chose to use FTP rather than a more sophisticated web approach so that we didn't have to have any software running on our in-house server (or deal with our IT staff!)
Basically, we use FTP files to do the exchange that was previously done on the phone. The server places a file on the FTP server containing the challenge phrase. The file's name is the customer's name. Our support staff have a program that automatically creates this file on our ftp site.
The customer is instructed by our staff to hit a hot key that reads the FTP file, authenticates it, and places a response file back on the server.
Our support staffs' software has been polling waiting for the customer's software to create the response file. When it sees the file, it downloads it and confirms its contents, and deletes it from the server.
You can of course have this exchange happen as many times and in either direction as you need in a given session in order to accomplish your goals.
The data in the files can have the same MD5 keys that you would use verbally, so that it is as secure as you'd like.
A weakness in this system is that the user has to have FTP access. We've found that the majority of our users (all businesses) have FTP access available. (Of course, your customer base may not...) If our application in the field is unable to access our FTP site, it clearly announces the problem so that our customer can go to their IT staff to request that they open the access. Meanwhile, we just fall back to the verbal codes.
We used the plain vanilla Indy FTP tools with no problem.
No doubt there are some weaknesses in this approach (probably including some that we haven't thought of.) But, for our needs, it has been fantastic. Our support staff and customers love it.
Sorry if none of this is relevant to you. Hope this helps you some.
I have a Linux/Apache/Rails stack hosting a data service. The data service is basically a front end for multiple data sources, akin to a federated search.
Queries to the service are authenticated via PKI. When handling each request, the PKI must be forwarded to each data source appropriate for the given request - each data source uses the PKI to control data access.
I know how to access the requestor's DN from Rails, but I haven't the first clue how to access the PKI or pass it along in web requests launched by the controller when handling the request. Any suggestions?
Your description makes it a bit hard to follow the organization, but Ill try to give this a shot.
The nature of PKI makes forwarding (proxying) a connection impossible, since the two endpoints set up a secret session key known only to those parties. It seems like you have 3 parties, a Client, an Intermediate, and an Endpoint. So the client can authenticate to the intermediate, and the intermediate now knows with certainty who the client is. I think your question is how to get the endpoint to know with certainty who the client is. The method I would choose is to have each intermediate have its own certificate, and authenticate to the endpoint itself (so now the endpoint knows who the intermediate is with certainty) then just have the intermediate pass the DN as some extra field that the endpoint will trust from the intermediate.
My Delphi program has a built-in protection mechanism to check for banned license keys on the Internet and displays a message to the user if a blacklisted key is found.
I'd like to store the blacklisted key in the registry, so if the user tries to re-enter it (and he/she is not connected to the Internet), it's not accepted.
What is the best way to hide an obfuscated entry in the Windows registry?
Thanks!
Edit: You guys have some good answers there, but I feel like I need to expand the question.
This is not mainstream software but a corporate one. Clients pre-pay one year and get a one-year license key for activation. The license key includes a machine ID and can't be used elsewhere.
The problem is that some clients tend not to pay in time or they don't pay at all. Since I don't want to bother with shorter than one year license keys (too much administrative overhead) I need a way to disable their licenses till they pay.
So the app now will connect to the Internet upon launch and check if their key is blacklisted. If it is, I need to disable access. In case they reinstall or block Internet access, I need to know if the key has been blacklisted.
Thus, I'm thinking it would be best to hide it in the registry. My users are not tech-savy enough to use registry tools to monitor the registry, but if I put it under HKLM/Software/MyCompany/MyProgram, some of them might do find it. So I need a place where they can't find it afterwards that it had been created. (Noone will be expecting it!)
Any ideas?
The eaysiest way to hide a key or a value is to create a key/value having '\0' inside of the name. You can do this wth respect of the native functions NtCreateKey (see http://msdn.microsoft.com/en-us/library/ff556468.aspx) NtSetValueKey (see http://msdn.microsoft.com/en-us/library/ff557688.aspx) which use UNICODE_STRING as parameters instead of LPCTSTR. You can read more about usage of native registry API in http://www.codeproject.com/kb/system/NtRegistry.aspx for example. A Delphi code you will find here http://www.delphi3000.com/articles/article_3539.asp.
UPDATED: Because many people read this question I want to add some words to my answer. I want divide the part of the question which we can read also in the title "best place to hide a key in the Windows Registry" from the subject with license keys. Because I read some answers (written before me) which concerned almost only the part of license keys and read practically no answer on the question from the title I wrote me answer.
The subject with license key I find very complex. It depends on the licensing model choosed. It's important how to generate, to distribute (to install) and to verify the key. Is key should be hardware depended or not? It can be one per computer or one per computer group. The key generation, key installation or key verification can be either with respect of some online services (also from the internet) or without there. I can continue... There are a lot of aspects, advantages and disadvantages of different approaches.
So I decide to answer only on the main question from the title which is clear and have a separate interest. All other questions about license key should be discussed in my opinion in the separate question after clearing all requirements.
UPDATED 2 based on the updated question: It seems to me in your case would be better to use some scenario based on cryptographic signing of an activation ticket. For example the schema can looks like following:
You software installed on the client computer will need an activation. Before activation it can not work or work in very restricted form (for example only some menus needed for software activation are enabled).
You write a server component which will be used by client during the activation to generate the license key based of the activation request received from the client.
If a client pay for the software you include the information about the client's "machine ID" (in any form which you want) in the database on the server.
After starting of the activation process from the client software (either at the program start of from menu or in any other way like you want) it collects some information about the computer like computer name ("machine ID"), some serial numbers or some other information about hardware or operation system which can not be changed without a new activation. This information the software send to your server (it is the activation request).
The server verify that the the client with the "machine ID" payed for the software and is not yet activated. Then the server calculate the hash (SHA1, MD5 or some other) from the information send from the client and sign the respond with the server's private key (or servers certificate). The signed ticket server will be send back to the client. This ticket will play the role of licence key.
The server can add any additional information to the ticket before signing. For example it can add the information about the date till one the software should be valid (for example, current day plus one year). So the ticket which will be send back to the client can contain the hash of input activation information and any additional information, all what you want. Important is only that the information should be signed. In general you can include full client's request as clear text in the servers ticket instead of including of the hash, but the usage of the hash a) reduce the ticket size and b) makes the ticket a little more secure.
Every client have public key corresponds to the private key used by server for signing of the activation ticket. The client save the ticket received from the server during activation in any place in registry of in the file system.
Every next time if the client software will be started the software will read the saved activation ticket from the registry (or from the file system). Then the software collect the same information, which are used for generation of the activation ticket, calculate the hash and compare it with the hash from the saved ticket. It verify of cause the signature of the ticket with respect of the public key (or with respect of the server's certificate). Moreover the software can verify any other additional policy information from the ticket like the time till one the ticket is valid.
All written is a roughly schema only, but it is very simple and it is extensible. You need only study how use some simple cryptographic operation and implement there in your software.
As a option you can don't have a server online, but instead of that implement in the software (in menu for example) a possibility to generate the activation request and send it per email for example. Then you can offline (!!!) generate an activation ticket based of the server request and send the ticket back to the client also per email. A simple Reg-file which can be imported by double-click or some other simple import possibility in your software (cut & paste in the activation dialog) can end the process of the software activation.
I don't think that the registry is a good place to hide such info, because anyone can download and use the Process Monitor (http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx) tool and see what your program does with the registry.
And thinking about this again. You will probably make users of your software unhappy if it will leave things in registry and other "secret" places on the user's hard drive. Locations like that are also easily discovered by tools that monitor what system functions your software calls.
As an alternative you could embed the banned keys in your application when you release new versions. This way the banned keys will be hidden in the application making it much harder for crackers to bypass the protection.
The downside of this is that a user can potentially run older version with a banned key with internet access blocked to your site, but if your software is actively developed with new features and bugfixes added, then nobody would want to run older versions. And if you are very paranoid you could release "updates" which update just the embedded banned key list.
But in the end no software protection scheme is perfect. If your software is popular enough there will always be a pirate cracker who will figure out your protection and make a patch or even a key generator.
If you really want to go that way, hash or encrypt the keys and then check the hashed or encrypted user key to those on the registry.
Be sure to check if there's any keys in the registry to be sure if the user didn't erased them.
It will be very challenging to achieve what you're trying to do, since a user can simply uninstall and re-install, and savvy users can wipe all traces of your app from the system (including the registry).
Other apps (like Windows, for example), instead of checking for a negative (banned key), instead check for a positive (good key). You "activate" the software once (when connected online) and this activation stores the "good key", which you can then check for whenever running the software (whether online or offline).
I'd suggest the second approach for you.
Note that there are ordinary end-consumer tools that monitor what applications write to the registry (like Cleansweep). This goes on API call level, so it will probably catch #0 workarounds too.
You could try to encrypt the whole shebang in a registry key, with something that uniquely identifies the machine (like a mac address) and a timestamp, to avoid that people can move the key to other machines. THen always require the presence of such key to startup, and demand to connect to internet for updates/activation if it is not there. (or the timestamp is very old)
I have figured out all the necessary steps to get DOD CAC card based client certificate authentication working in Apache, but am now struggling to pull a good GUID for the user from the certificate I am receiving. Is there a GUID available on the certificate that will not change when the CAC card is renewed? I was thinking of using the SSL_CLIENT_S_DN which would look something like:
/C=US/O=U.S. Government/OU=DoD/OU=PKI/OU=CONTRACTOR/CN=LAST_NAME.FIRST_NAME.MIDDLE_NAME.0123456789
but I have heard that the number on the end changes when the CAC card is renewed. Is this true? Is there a better piece of information to use for a GUID? I'd also like to get the users email address, but I don’t see it available in the information I am receiving from the certificate. Is the email adress available in some custom extension that I am not seeing?
Thanks!
We have run into plenty of instances where that number on the end changes. We were eventually beaten into using a process where that if a user gets a new CAC, we require that the user re-associate that new card with their user account. That's the process on most DoD systems now, such as DKO (Defense Knowledge Online) and others. If we do not have the supplied CAC certificate's data in our database, the user must log onto the system using a username and password. If the credentials are correct, the identifying information of that CAC is associated with the user's account in the system.
At least that's how we did it.
And, as far as, getting access to the email address, #harningt is correct. It depends on which certificate is supplied to you.
The DOD EDI PIN should NOT change.
I can give you plenty of instances where you can go to the DOD411 site (CAC required) to look up somebody and it will show certificates from when they were a contractor and then show the same person again, now as a DOD civilian (we see this alot with new hires).
I just looked up one of our new hires who has variously been in the Air Force, then a contractor for the Navy, then a contractor for the Army, and now works for us as a DA Civilian.
Same DOD EDI PIN.
The CN (Common Name) can change (e.g. resulting from marriage), but the ten digit DOD EDI should not change.
As to what certificate to authenticate against, most sites are authenticating against the email cert, but some do use the identity cert instead.
Mike
I'm sure you've all figured out your answers by now. But for others coming to this post later just a couple notes:
This is the DISA reference site:
http://iase.disa.mil/pki-pke/
PKI is the infrastructure, PKE is enabling your computers/servers/applications with PKI auth
This is the PKE admin getting started guide:
http://iase.disa.mil/pki-pke/getting_started/Pages/administrators.aspx
First, many PKI-enabled DOD sites should support hardware tokens issued through commercial CAs that participate in the DOD's ECA program (Verisign, IdenTrust, ORC). These ECA-issued certificates don't even include this "number", the DOD EDI PN.
As I understand it, there is supposed to be some effort made to keep the number stable for a particular person. For example even if I quit my civilian job at the DOD and go to work for a contractor, get married and change my name, quit my job and enlist in the Coast Guard, my DOD EDI PN should be the same. However, in practice, I doubt it works like that.
And even if it did, I probably shouldn't have the same access to an application. Each time my employment changes, the certificate on my CAC should be revoked. If an application is only looking at the common name or subject alternative name of the certificate, it will miss changes in the organization that probably affect the authorization of that subject.
Basing authentication on a particular certificate (issuer and serial number) is a pain for users, but it does make sense from a standpoint of security and robustness.
I have heard the argument for using the number on the end as the unique identifier for individuals because the other information (name, organization, etc) are the bits of information that can realistically change over time as opposed to the number. However, I have not seen an official document or any other piece of authoritative information that actually states this as a fact.
Just curious, is there a document that speaks to the step-by-step process of enabling Apache and DOD CAC? That's what actually brought me to this question in the first place :)
The email address is available in the Subject Alternative Name fieldset. This depends on CAC certificate, but that used for SSL login should contain it (it's also the email signing cert).
The subject would not likely change for a given person very often. The number is indeed the unique number identifying a person. This number would also be present in a UPN field in the Subject Alternative Name for windows login (in a form such as NUMBER#MIL)
You could retrieve the owners SSN from the PIV. That will not change