While screening the bugs at sourceforge I found this one. I assume last
patch I sent regarding this solved this too, right?

Thanks Hal,
Rajiv Andrade
IBM LTC Security Development

On Fri, 2009-10-16 at 14:23 -0700, Hal Finney wrote:
> I have noticed a similar problem in Tspi_TPM_CollateIdentityRequest.
> If the TPM policy is set to use TSS_SECRET_MODE_POPUP, which is
> convenient, the popup never appears for this function. As a workaround
> I first do a dummy call to Tspi_TPM_OwnerGetSRKPubKey, which does do
> the popup, and then Trousers caches the password.
> 
> However for changing auth, you would not want it to cache the old one
> when reading the new one, so some care might be necessary to get that
> one to work right.
> 
> Hal Finney
> 
> On Fri, Oct 16, 2009 at 1:29 PM, Wyllys Ingersoll
> <[email protected]> wrote:
> > Rajiv Andrade wrote:
> >> Hi,
> >>
> >> I've been already taking a look at your previous email about this.
> >>
> >> The main issue is that the hNewPolicy parameter is described as:
> >> "Handle of the policy object _providing the new authorization data_."
> >>
> >> The authorization data prompt should be done using Tspi calls, I agree,
> >> but not necessarily inside Tspi_ChangeAuth.
> >>
> >> So, for the new policy you're submitting to Tspi_ChangeAuth you must
> >> call Tspi_Policy_SetSecret() with TSS_SECRET_MODE_POPUP mode set. Are
> >> you doing it this way? The same must be done with the currently assigned
> >> key object's policy. Let us know if it still doesn't work.
> >
> > Correct, the code that we are trying to use is using TSS_SECRET_MODE_POPUP
> > for both the hTPM policy and also for the new usage policy.  Tspi never 
> > prompts
> > for either one.
> >
> > Ex:
> >          if (set_object_policy(hTPM, TSS_SECRET_MODE_POPUP, 0, NULL))
> >                 return (ERR_FAIL);
> >
> >          /* new policy object */
> >          ret = Tspi_Context_CreateObject(hContext, TSS_OBJECT_TYPE_POLICY,
> >              TSS_POLICY_USAGE, &hNewPolicy);
> >
> >         if (ret) {
> >                  print_error(ret, gettext("Create policy object"));
> >                  return (ERR_FAIL);
> >        }
> >         ret = Tspi_Policy_SetSecret(hNewPolicy, TSS_SECRET_MODE_POPUP,
> >             0, NULL);
> >          if (ret) {
> >                  print_error(ret, gettext("Set policy object secret"));
> >                  return (ERR_FAIL);
> >          }
> >
> >          ret = Tspi_ChangeAuth(hTPM, NULL, hNewPolicy);
> >           if (ret) {
> >                  print_error(ret, gettext("Change authorization"));
> >                  return (ERR_FAIL);
> >          }
> > ...
> >
> >
> > As a test, I have hacked the code in changeauth_owner to do the following
> > at the very beginning:
> >
> >        TCPA_SECRET secret;
> >        TSS_HOBJECT hPolicy;
> >        if ((result = obj_tpm_get_policy(hObjectToChange, TSS_POLICY_USAGE, 
> > &hPolicy)))
> >                return result;
> >
> >        if ((result = obj_policy_get_secret(hPolicy,  TR_SECRET_CTX_NEW, 
> > &secret)))
> >                return result;
> >
> >        if ((result = obj_policy_get_secret(hNewPolicy, TR_SECRET_CTX_NEW, 
> > &secret)))
> >                return result;
> >
> >        if ((result = authsess_xsap_init(tspContext, hObjectToChange, 
> > hNewPolicy,
> >                                        TSS_AUTH_POLICY_REQUIRED, 
> > TPM_ORD_ChangeAuthOwner,
> >                                        TPM_ET_OWNER, &xsap)))
> >        ...
> >
> >
> >
> > In the above code the "secret" data is ignored.  obj_policy_get_secret is 
> > just being
> > called because it is the only way to trigger the call to popup_GetSecret, 
> > the result
> > is irrelevant because the actual auth data gets extracted by 
> > authsess_xsap_init.
> >
> > This does indeed prompt for 2 Passwords and the command then succeeds, 
> > though I
> > don't think this is the correct solution.  Also, doing it this way, the 
> > user gets the
> > same prompt for both the current password and the new one so its not very 
> > intuitive as to
> > which one is being prompted.
> >
> >
> > -Wyllys
> >
> >
> >>
> >> Thanks,
> >> Rajiv Andrade
> >> IBM LTC Security Development
> >>
> >> On Fri, 2009-10-16 at 15:23 -0400, Wyllys Ingersoll wrote:
> >>> Is it a bug that one cannot use the TSS_SECRET_MODE_POPUP mode for the
> >>> old and new policies when calling Tspi_ChangeAuth?
> >>>
> >>> Ideally, I would like to utilize the built-in prompting mechanisms
> >>> instead of having to write my  program to prompt for the passwords,
> >>> but Tspi_ChangeAuth never calls the functions that cause the user
> >>> to be prompted, they just return "auth failed" if the POPUP method
> >>> is specified because the auth secrets never get initialized.
> >>>
> >>> This seems like a bug, the spec does not say that you cannot use
> >>> those modes with the policies involved in the ChangeAuth command.
> >>>
> >>> thoughts?
> >>>
> >>> thanks,
> >>> -Wyllys


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
TrouSerS-tech mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/trousers-tech

Reply via email to