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
게시자: drumlee00 
