Prompt-x

1. Introduction

BONDI 는 API 들을 정의하고, 이 API에 접근을 요청하는 Widget 의 접근을
제어하여 악의적인 요청으로 부터 device 를 보호하고 있습니다.

현재 BONDI는 XACML (eXtensible Access Control Markup Language )을
기반으로 compact 한 XML format 을 이용하여 API에 대한 접근을 제어하고
있습니다.
( 참고 : http://bondi.omtp.org/1.1/security/bondixml.rnc.txt – DTD)

이 포스트에서는 복잡한 알고리즘 보다는 실제 접근 제어에 사용되는
efftect value 인 Prompt-x에 대해서 알아보기로 하겠습니다.

2. Prompt-x

effect 에 들어갈 수 있는 value 는 총 5가지가 있다. 그 value 는 다음과 같습니다

  • permit – This effect allows requested access without user interaction.
  • deny – This effect denies requested access without user interaction.
  • prompt-oneshot – This effect allow requested access after explicit confirmation by the user.
  • prompt-session – This effect allow requested access after explicit confirmation by the user.
  • prompt-blanket – This effect allow requested access after explicit confirmation by the user.

이 중 permit과 deny는 별다른 user interaction이 없는 value 이므로
별다른 혼란이 없이 사용되어 집니다.  하지만 prompt-x로 되어 있는 것들은
명백한 사용자의 확인에 의해서만 해당 API에 접근할 수 있는 value입니다.

prompt 의 경우 각 value별로 적용이 가능한 option을 보여주는 대화상자
(dialog)로 user와 interaction을 하게 됩니다. 이제 prompt 의 종류별로
어떠한 조건으로 user와 interaction 하는지 알아 보겠습니다.

2.1 prompt-oneshot

이 value의 spec을 먼저 보면 다음과 같습니다.
“deny always”, “deny this time”, “allow this time”
이 것은 user의 확인을 요하는 dialog에서 위와 같은 list를 주어
user 에게 해당 request 에 대한 확인을 요청하게 됩니다.
그 후 user는 위에 정해진 값 중 한가지를 선택하여 request에 대한
제어를 하게 됩니다.

(prompt-oneshot의 범위 : 해당 API에 대한 요청에 단 한 번만 유효함
                                      이후 동일 API에 대한 요청이 있으면 다시
                                       user의 확인 후 API 접근 가능.
                                      -단, deny always의 경우 WRT engine이 종료 
                                       될 때까지 유지)

2.2 prompt-session

이 value의 spec을 먼저 보면 다음과 같습니다.
prompt-oneshot options plus “deny for this session”,
“allow for this session” 이 것은 prompt-oneshot 에 있는
option에 다음과 같은 “deny for this session”,
“allow for this session” list를 추가하여 user의 확인을
요하는 dialog를 띄워 user 에게 해당 request 에 대한
확인을 요청하게 됩니다. 그 후 user는 위에 정해진 값 중
한가지를 선택하여 request에 대한 제어를 하게 됩니다.

(prompt-session 의 범위 : widget application이 실행되어 있는 상태)

2.3 prompt-blanket

이 value의 spec을 먼저 보면 다음과 같습니다.
prompt-session options plus “allow always”.
이 것은 prompt-session 에 있는 option에 다음과 같은 “allow always” 
list를 추가하여 user의 확인을 요하는 dialog를 띄워 user 에게 해당
request 에 대한 확인을 요청하게 됩니다.
그 후 user는 위에 정해진 값 중 한가지를 선택하여 request에 대한
제어를 하게 됩니다.

(prompt-blanket 의 범위 : WRT engine이 실행되어 있는 상태
                                        단, engine 이 static module 로 구동 될 경우
                                         terminal 이 off 되기 전까지)

3. Opinion

어떠한 보안도 100%로 안전하다고 볼 수는 없지만 현재 BONDI에서는 보안 문제에 상당히 많이 힘쓰고 있습니다. 처음에는 단순히 XML file에 접근제어 값을 넣어 제어하던 방식에서 현재는 signed policy document, provisioning 을 통한 policy update 등 많은 발전이 있었습니다. 그래도 부족한 점이 있겠지만 이렇게 계속 보안에 힘을 쏟는다면 그래도 사용자가 안전하다고 믿고 사용할 수 있는 product가 될 것이라 믿습니다. 마지막으로 제 포스트에 문제가 있으면 답글로 남겨 주시면 리뷰 후 정정 하도록 하겠습니다.

4. Reference

http://bondi.omtp.org/1.1/security/BONDI_Architecture_and_Security_Appendices_v1.1.pdf

답글 남기기

아래 항목을 채우거나 오른쪽 아이콘 중 하나를 클릭하여 로그 인 하세요:

WordPress.com 로고

WordPress.com의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Twitter 사진

Twitter의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Facebook 사진

Facebook의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Google+ photo

Google+의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

%s에 연결하는 중

%d 블로거가 이것을 좋아합니다: