Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
HBX security (was: RE: [higgins-dev] Notes from today's Higgins development)

What I’m saying is that I think it would be harder for a malicious browser add-on to attack the native code portion of HBX than to attack today’s _javascript_ code. For example, it would be harder to reverse engineer how HBX signs messages destined for the remote agent.

In any case, the overall issue I’m struggling with is HBX security…On the call today, Mike put forward (as Abhi did months ago) the suggestion that in H1 and H3 the i-card selection UI code should move out of HBX and into a separate app (native or not), and thus live in a separate process. This app is what in our architecture we now call the “I-Card Selector” app. If this app had the option of talking to either a local or a remote RPPS agent service (as is already shown in the architecture diagram), then the app could be used for all Higgins deployment configurations. I think this approach would address most or all of the security concerns I have with today’s HBX. Are you supportive of this direction?

 

On the downside…compared to where we are today with H1, this approach will be harder to install. First it will require a bigger download. Second it will involve elevated rights on the target machine. Third, it will require a more sophisticated installer (at least for Windows). All of three of which we can likely deal with.

 


From: higgins-dev-bounces@xxxxxxxxxxx [mailto:higgins-dev-bounces@xxxxxxxxxxx] On Behalf Of Anthony Nadalin
Sent: Thursday, July 26, 2007 2:42 PM
To: Higgins (Trust Framework) Project developer discussions
Cc: 'Higgins (Trust Framework) Project developer discussions'; higgins-dev-bounces@xxxxxxxxxxx
Subject: RE: [higgins-dev] Notes from today's Higgins development call (noon ET)

 

And how does native code help that ? I agree that there are security issues, but I don't agree that native code is the way to fix all these. So in your scenario how do you know the browser itself is not infected ?

Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122

Inactive hide details for "Paul Trevithick" ---07/26/2007 01:29:19 PM---Here’s an example of an issue… In the H1 configuratio"Paul Trevithick" ---07/26/2007 01:29:19 PM---Here’s an example of an issue… In the H1 configuration HBX communicates with the back end “agent service” (RPPS, etc.). For


From:


"Paul Trevithick" <paul@xxxxxxxxxxxxxxxxx>


To:


"'Higgins \(Trust Framework\) Project developer discussions'" <higgins-dev@xxxxxxxxxxx>


Date:


07/26/2007 01:29 PM


Subject:


RE: [higgins-dev] Notes from today's Higgins development call (noon ET)





Here’s an example of an issue… In the H1 configuration HBX communicates with the back end “agent service” (RPPS, etc.). For the agent service to know that it is talking to a legitimate, unmodified copy of HBX and not a rogue, HBX may need to hold a secret (e.g. a key). Because HBX is in _javascript_ I can’t see how it can keep this key from being discovered by another browser add-on.


From: higgins-dev-bounces@xxxxxxxxxxx [mailto:higgins-dev-bounces@xxxxxxxxxxx] On Behalf Of Anthony Nadalin
Sent:
Thursday, July 26, 2007 2:12 PM
To:
Higgins (Trust Framework) Project developer discussions
Cc:
'Higgins (Trust Framework) Project developer discussions'; higgins-dev-bounces@xxxxxxxxxxx
Subject:
Re: [higgins-dev] Notes from today's Higgins development call (noon ET)

I don't understand the issue around "native" code being more "secure", as its not, in the Cardspace case its not that its native code its that it runs with some process isolation

Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122

Inactive hide details for "Paul Trevithick" ---07/26/2007 01:02:32 PM---Attendees"Paul Trevithick" ---07/26/2007 01:02:32 PM---Attendees


From:


"Paul Trevithick" <paul@xxxxxxxxxxxxxxxxx>


To:


"'Higgins \(Trust Framework\) Project developer discussions'" <higgins-dev@xxxxxxxxxxx>


Date:


07/26/2007 01:02 PM


Subject:


[higgins-dev] Notes from today's Higgins development call (noon ET)






Attendees
=========
Alex Amies - IBM
* Paula Austel - IBM
Jeff Broberg CA
Andy Hodgkinson - Novell
Duane Buss - Novell
* Greg Byrd - NCSU/IBM
* Brian Carrol - Serena
* Tom Doman - Novell
Valery Kokhan - Parity Ukraine
David Kuehr-Mclaren - IBM
* Mike McIntosh - IBM
Nataraj Nagaratnam - IBM
Dale Olds - Novell
Uppili Srinivasan - Oracle
Drummond Reed - Cordance
* Bruce Rich - IBM
* Mary Ruddy - Parity/SocialPhysics
* Markus Sabedello - Parity
* Jim Sermersheim - Novell
* George Stanchev - Serena
* Daniel Sanders
Abhi Schelat - IBM
* Paul Trevithick - Parity/SocialPhysics
Igor Tsinman - Parity
--
* Present

Agenda
======
1) New deployment (see [1])
2) Progress on build automation (configuration, idas, icard)
3) Milestone 0.9 progress (see [2])
4) HBX: security considerations, native code
5) HBX: need for IE version
6) CardStoreStrategy: status update

[1]
http://wiki.eclipse.org/Deployments#RP_Enablement:_CardSpace-interoperable_R
elying_Party_Demo_App
[2]
http://wiki.eclipse.org/index.php/Milestone_0.9


1) New Deployment (see [1])
---------------------------
* Paul created this new table
* Bruce agreed to be the owner and to fill in the needed wiki pages
* Brian pointed out that we (he!) should add another deployment: ALF/STS
integration

2) Progress on build automation
-------------------------------
* Since Valery couldn't be on the call Paul mentioned that we should by
tomorrow have a new approach working for these components: (configuration,
idas and icard). The new approach involves making modifications to the
existing eclipse2ant plugin to make it produce buildaux.xml along wit
hbuild.xml and dependency.xml.

* Mike asked if the new approach was well documented (so he could try it
with STS).

* Paul agreed that after tomorrow, we'd pause to document the new approach
on the wiki, and then resume enhancing it some more.

3) Milestone 0.9 progress (see [2])
-----------------------------------
* There was a brief discussion as to whether we should delay M0.9 and
declare it done only when all Components can be automatically/nightly built

4) HBX: security considerations, native code
--------------------------------------------
* Paul began the discussion by explaining that the HBX needs some native
code in order to make it more secure (e.g. harder for hackers to make rogue
HBXes, hardened from attack by other browser plug-ins, etc.)

* Mike suggested that we should go further. HBX should just launch a native
"I-Card Selector" app (as both Microsoft CardSpace and Higgins H2 do it) and
get rid of HBX's UI code.

* Paul: This would work if the I-Card Selector app could be used to either
consume a local agent service (RPPS and on down). [This is exactly what the
Novell folks have been planning for H2 --a local or remote agent service]

* Jim pointed out that the Novell H2 I-Card Selector can run on any platform
(including Windows).
* In summary the requirements are:
o uses native code
o is relatively small in size
o can be configured to use a local or remote agent service

* It does appear that these requirements could be met by using a native
I-Card Selector component/app as an alternative to adding some native
security code to HBX

* This approach has the benefit that creating other versions of HBX (e.g.
for IE and Safari) is much easier because there is less code in HBX

* Mike reminded us all that security and install-ability are key for 1.0

5) IE HBX --was not discussed

6) CardStoreStrategy --nobody from IBM Zurich was on the line so we didn't
get an update.

Action Items
============
Bruce: to flesh out wiki page for RP demo app configuration

Brian: to add a new table to Deployments page for ALF's STS integration

Valery: after tomorrow, document the new build approach well on the wiki.
Well enough that MikeM could try to apply it to the STS components.

Paul/Mary: consider delaying M0.9 until nightly build situation is done

Paul: consider moving HBX UI into I-Card Selector app; evaluate existing H2
I-Card Selector code. Can it be modified to be used in the H1 deployment
configuration?




_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev


Back to the top