[Openstack-sigs] [security] A Security Project Proposal

TING PANG chengfeiyoiua at gmail.com
Wed Oct 31 13:45:57 UTC 2018


Hi Luke,

Apologize for the delay getting back to you. I have been on a business trip
for the last two weeks.

The problem you concerned does exist and it needs to be addressed. We have
some preliminary ideas, for example, encrypting the state "trusted" before
storing it on the disc, storing the state "trusted" on the non-volatile
memory provided by a trusted chip. Perhaps you have a better idea and we
hope we can solve this problem through active community discussions.

I also bring up about the main focus of our proposal. In recent years, the
trusted computing technology has been widely used and there are several
different trusted formats in the world. It is necessary for OpenStack to
schedule various trusted resources on the cloud side. So we want to have
the same management plane for various trusted computing hardware (such as
TPM, TCM, Titan, ... ) in OpenStack.

If you have any further questions or concerns, please don't hesitate to
contact me. Looking forward to your insight.

Best Regard,

Ting

Luke Hinds <lhinds at redhat.com> 于2018年10月17日周三 下午11:24写道:

> Hi Ting,
>
> Here's my thoughts on the topic / proposal.
>
> To jump straight to my main concern, I am sceptical of storing a 'trust
> state' in yet another API, especially for trusted compute, as we then need
> to trust an API and it's less secure (than a TPM) components (database,
> memory, disc etc).
>
> Up to present the trusted compute approach in OpenStack has been always
> been some type of API query to establish if a node can be 'trusted' and
> hooking that into nova's scheduler. One current approach being the traits
> API.
>
> The problem with this is that the stored state of 'trusted' is then on
> disc or volatile memory , typically a row in a mariaDB table somewhere on
> the controller - this then means we immediately lose all of the true
> attractiveness of a TPM, that being a tamper proof hardware route of trust
> ,  unlike an API which sets the 'trust state' in a datastore on disc or
> memory (which can be hacked to spoof trust).
>
> So I can't really comment on the current proposal or really get behind it,
> as its to vague at present in why it should provide unified trust and how
> we would trust it. On the face of it, this proposal appears to be another
> actor susceptible to the flaws outlined above. I would need to know how the
> above concern would be resolved, so that there is implicit hardware routed
> trust presented to the workload wanting a trusted node to schedule upon,
> without a go between actor hosting the trust state of compute nodes.
>
> Perhaps you have already solved this, if so I would recommend you outline
> it in your proposal.
>
> Best Regards,
>
> Luke
>
> On Wed, Oct 17, 2018 at 3:48 PM TING PANG <chengfeiyoiua at gmail.com> wrote:
>
>> Dear all,
>>
>> As we all known, security has always been a hot topic among people. In
>> OpenStack, if an attacker make a system un-trustworthy, it will make a
>> risk for entire infrastructure and affect customers confidence.
>> Fortunately, more and more vendors start providing security solutions with
>> the trusted computing. It is a security technology based on a hardware
>> trust format to improve system integrity and trustworthy. The risks and
>> threats on cloud can be mitigated and managed with trusted computing
>> technology, which can make a customer more confident when utilizing
>> OpenStack.
>>
>> However, there are some mainstream trusted formats (e.g. TPM, TCM) and
>> some special trusted formats provided by vendors (e.g. Google, Microsoft )
>> in the world, which cause huge development costs and interoperability
>> issues for vendors to support various trusted formats.
>>
>> To resolve problems above, we want to create a new security project named
>> "Hawthorn" that provides a general unified trust management framework to be
>> compatible with different trust formats in OpenStack.
>>
>> More general information can be found here:  *https://wiki.openstack.org/wiki/Hawthorn
>> <https://wiki.openstack.org/wiki/Hawthorn>*
>>
>> Please feel free to contact me if you are interested in this proposal or
>> have questions and suggestion.
>>
>> Best regards,
>>
>> Ting
>>
>> _______________________________________________
>> openstack-sigs mailing list
>> openstack-sigs at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs
>>
>
>
> --
> Luke Hinds | NFV Partner Engineering | CTO Office | Red Hat
> e: lhinds at redhat.com | irc: lhinds @freenode | t: +44 12 52 36 2483
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-sigs/attachments/20181031/5c24112a/attachment.html>


More information about the openstack-sigs mailing list