When a data user requires access it asks the key issuer to generate a key for it using the specified attributes.
How does the key issuer authenticate that the data user actually acquires the attributes it claims to possess?
Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. It only takes a minute to sign up.Sign up to join this community
In fact there is a setup phase during which one will take the attributes one wants to publicly disclose, and will generate a discrete logarithm public key, so to say, for each of those attributes and a key generation phase during which the same "authority" will generate private keys for each of those attributes.
One can then publish the set of attributes, the "set of attributes' public keys", as well as a randomly chosen integer $y$. And those publicly disclosed keys can then be used to encrypt data for a subset of those attributes, by whoever wishes to do so.
Now, the magic of ABE is that when you decide to encrypt for a given subset of attributes, only the persons owning all of the corresponding attributes' private keys (generated at the key generation phase by the "authority") can then combine this subset of keys in order to decrypt that ciphertext.
The persons who do possess all of these attributes' private keys can then perform the so called decryption phase, which will the bilinear map $e$ used to "stitch together" the plaintext only if the ciphertexts was addressed to the given subset of attributes out of all the attributes' keys one may possess.
However the way one distributes the attributes and their corresponding private keys created during "setup" to individuals for them to perform "key generation", is not taken into account by the scheme itself and should obviously be done in a secure, authenticated way which deals appropriate attributes to each individuals.
So, the "authority" generating the public keys and the private keys must effectively assign the attributes' private keys to the people who "own" those attributes, but the ABE schemes themselves do not take care of this practical aspect of the problem.
I'm assuming CP-ABE, because it is easier to understand, but this is also applicable to KP-ABE in the same way.
Almost no Attribute-based Encryption scheme discusses how it is to be used in the real world. We can just infer how it is to be used from the information that is passed into the four algorithms: setup, keygen, encrypt, decrypt.
Setup takes a security parameter that is not mentioned anywhere else and outputs a public key and a master secret key. The master secret key is used during keygen which means that keygen must be executed by some kind of central authority.
If anybody could query the central authority for some keys with attributes of their choice, then the whole system would be horribly broken. That's what you're asking. The only answer can be that the users don't actually have the ability to decide themselves which attributes they have.
The central authority can be modeled as a server which has a database of users and some administrators. The administrators assign specific attributes to specific users. The users either must register themselves beforehand or be made available from the central identity management system in the case of an enterprise. It's entirely possible that users list the attributes they want to have during registration or subsequent requests, but an administrator (or other users they delegate this right to) must look through these requested attributes and assess whether they make sense for that user. This process is much easier in an enterprise where users are known much better than anonymous users on the internet who are known by some (trash) mail address.
The actual networked authentication of the user at the central authority server can be anything you can think of: email+password, multi-factor authentication, OAuth, OpenID Connect, ADFS, SAML, LDAP, Kerberos, RADIUS, IEEE 802.1X, etc. (very wild bunch just for illustration purposes)
Users must successfully authenticate themselves against the central authority and administrators must authorize known users to have specific attributes. This is essentially a mapping table in the database. After the user authenticated, they can request their actual key from the central authority, which looks up all the mappings from the database and builds the user private key containing all the authorized attributes.
Now the efficiency of ABE theoretically comes in: the encrypting user and the decrypting user don't need to contact the central authority, because the actual data authorization mechanism is delegated to the cryptography of ABE. In practice, they still have to contact the central authority regularly, in case they think that the administrator assigned more attributes to them.
These are the reasons why ABE didn't take off widely (at least as far as I tried to use ABE for 2 years).
I must say, that the only system I know of that has some additional benefit compared to a trivial system is described in this Master's thesis: Combining ABCs with ABE by T.R. van de Kamp. It delegates the authorization of attributes at the central authority to a different entity (which also has administrators assigning attributes).
Don't get me wrong, there are many very interesting schemes with a variety of intriguing features, but the use cases seem very contrived when you're actually thinking about using it in the real world.